Le 13/08/2013 01:19, Ian P. Cooke a écrit :
I'm reminded of the work done at Microsoft the showed that Observable
and Enumerable were duals (e.g.
http://csl.stanford.edu/~christos/pldi2010.fit/meijer.duality.pdf
http://csl.stanford.edu/%7Echristos/pldi2010.fit/meijer.duality.pdf )
The relevant
Le 11/08/2013 23:18, Jens Nockert a écrit :
for i in iterations {
…
if converged {
break;
}
}
if iterations.finished() {
fail!(Oh noes, it did not converge);
}
The only way to implement .finished() non destructively (so that, when
returning false, it does not eat an element)
The only way to implement .finished() non destructively (so that, when
returning false, it does not eat an element) is with a Peekable iterator as
in this pull request:
https://github.com/mozilla/rust/pull/8428
Then .finished() is .peek().is_none().
If you loop all the way through the
Le 12/08/2013 18:23, Micah Chalmer a écrit :
The for-loop already knows how it exited.
It only knows if something explicitly makes it know. This boils
down to one of two things: either the boolean flag approach as
discussed earlier, or the compiler turning every break in the block
into an
Given that many people have noted that they've never used it in python,
and nobody seems to agree on what the intuitive behavior for it would
be, and all such behaviors can be implemented via macros, I think we'll
pass.
-Graydon
___
Rust-dev mailing
On Mon, Aug 12, 2013 at 2:54 PM, Simon Sapin simon.sa...@exyr.org wrote:
fn main() {
let v = ~[1u, 7, 42, 0];
let mut it = v.move_iter().enumerate();
for_!((i, v) in it {
if v == 42 {
printfln!(Found it at %u, i);
break
}
} else {
Le 12/08/2013 20:16, Corey Richardson a écrit :
On Mon, Aug 12, 2013 at 2:54 PM, Simon Sapin simon.sa...@exyr.org wrote:
fn main() {
let v = ~[1u, 7, 42, 0];
let mut it = v.move_iter().enumerate();
for_!((i, v) in it {
if v == 42 {
printfln!(Found it at %u,
I'm reminded of the work done at Microsoft the showed that Observable and
Enumerable were duals (e.g.
http://csl.stanford.edu/~christos/pldi2010.fit/meijer.duality.pdf )
The relevant idea is that a richer interface that includes wether the the
subject completed normally or via exception is
I'm not very familiar with Python at all, coming from C++ land. At first
glance, I must say that this seems totally backward and not desirable;
I'd wager any case where this for...else would come in handy has an
alternate design that is just as sexy (or more) and does not require the
pattern.
I wouldn't call myself a Python programmer, but I have written a lot of Python
and I know quite a few that do use and love the for-else construct.
The most common (if not only?) usage that I have seen is something like
for i in xrange(…):
some-algorithm…
if coverged:
break
Le 11/08/2013 06:53, Tom Lee a écrit :
I think your code will be more explicit if you declare a mut bool
check its state post-`break`. :)
Resorting to boolean flags to cope with insufficient control flow feels
like Basic, which makes me sad :(
--
Simon Sapin
To be clear: should that `if` test be if not converged ?
On Sun, Aug 11, 2013 at 1:18 AM, Jens Nockert j...@nockert.se wrote:
I wouldn't call myself a Python programmer, but I have written a lot of
Python and I know quite a few that do use and love the for-else construct.
The most common
On Sun, Aug 11, 2013 at 1:06 PM, Simon Sapin simon.sa...@exyr.org wrote:
Le 11/08/2013 06:53, Tom Lee a écrit :
I think your code will be more explicit if you declare a mut bool
check its state post-`break`. :)
Resorting to boolean flags to cope with insufficient control flow feels
like
On 8/12/13 8:25 AM, Tom Lee wrote:
:) I can appreciate that, but I'm still not really convinced that this
problem deserves more syntax.
That said, I might hate for..else less if it used something other than
the 'else' keyword. *shrug*
It seems to me that a big benefit of macros in Rust is to
On Sun, Aug 11, 2013 at 1:27 PM, Patrick Walton pwal...@mozilla.com wrote:
On 8/12/13 8:25 AM, Tom Lee wrote:
:) I can appreciate that, but I'm still not really convinced that this
problem deserves more syntax.
That said, I might hate for..else less if it used something other than
the
On H.25/08/11, at 22:20, Tom Lee rust-...@tomlee.co wrote:
To be clear: should that `if` test be if not converged ?
No, the else in Python executes if the for loop consumes the whole iterator,
and you want to fail if it does not converge.
___
On 12 Aug 2013, at 00:09, Tom Lee rust-...@tomlee.co wrote:
Anyway, this sort of confusion is exactly why I don't like for..else. But
then maybe I'm the only one that's confused here. :)
Obviously you were not the only one, since there was a long thread without
clarification.
While I think
On Sun, Aug 11, 2013 at 3:18 PM, Jens Nockert j...@nockert.se wrote:
On 12 Aug 2013, at 00:09, Tom Lee rust-...@tomlee.co wrote:
Anyway, this sort of confusion is exactly why I don't like for..else. But
then maybe I'm the only one that's confused here. :)
Obviously you were not the only
On Sun, Aug 11, 2013 at 6:32 PM, Tom Lee rust-...@tomlee.co wrote:
On Sun, Aug 11, 2013 at 3:18 PM, Jens Nockert j...@nockert.se wrote:
On 12 Aug 2013, at 00:09, Tom Lee rust-...@tomlee.co wrote:
Anyway, this sort of confusion is exactly why I don't like for..else. But
then maybe I'm the
Hi,
On 11/08/2013 23:47, Daniel Micay wrote:
Python does not make the guarantee, and the functions like `zip` there
will continue calling the underlying iterators.
That's incorrect. Python's definition of the iterator protocol is that
an iterator not continue raising StopIteration is in
On Sun, Aug 11, 2013 at 6:58 PM, Armin Ronacher
armin.ronac...@active-4.com wrote:
Hi,
On 11/08/2013 23:47, Daniel Micay wrote:
Python does not make the guarantee, and the functions like `zip` there
will continue calling the underlying iterators.
That's incorrect. Python's definition of
Hi,
On 12/08/2013 00:10, Daniel Micay wrote:
Perhaps it's a violation of the protocol to stop raising
StopIteration, but zip will continue to cause side effects like I/O.
It's undefined what happens if you continue producing items after you
stopped. There are no safeguards in place. However
For reference, in my iterative proposal, I've been considering adding a
`.finished()` method to the Fuse adaptor, which would let you easily add that
capability to any iterator.
-Kevin Ballard
On Aug 11, 2013, at 6:47 PM, Daniel Micay danielmi...@gmail.com wrote:
On Sun, Aug 11, 2013 at
Le 10/08/2013 15:56, Jordi Boggiano a écrit :
On 10.08.2013 16:10, Simon Sapin wrote:
Proposal:
for i in iter {
// ...
} else {
// ...
}
The optional else block is executed when the for loop stops without
exhausting the iterator, ie. when break is used.
Maybe
In all my programming career as a python programmer I have never used a
for-else construct. In fact, I won't be able to tell you exactly when the
else-block is executed off the top of my head either. Even though that
probably speaks more about me as a programmer than about the python
language, it
Le 10/08/2013 15:10, Simon Sapin a écrit :
Proposal:
for i in iter {
// ...
} else {
// ...
}
The optional else block is executed when the for loop stops without
exhausting the iterator, ie. when break is used.
Typical usage is finding an element in a
On 8/10/13 7:10 AM, Simon Sapin wrote:
Hi,
Now that the for loop is based on external iterators, can we reconsider
for-else?
Proposal:
for i in iter {
// ...
} else {
// ...
}
The optional else block is executed when the for loop stops without
On 08/10/2013 07:24 PM, Paul Nathan wrote:
On 8/10/13 7:10 AM, Simon Sapin wrote:
Hi,
Now that the for loop is based on external iterators, can we reconsider
for-else?
Proposal:
for i in iter {
// ...
} else {
// ...
}
The optional else block is executed
I'm a big Python user, but I'm -1 on for..else -- mostly because of the
choice of the else keyword.
The issue is that it's downright misleading. You don't look at the 'else'
clause and think oh, I don't know what that means go look up the docs
like you might with other unfamiliar parts of a new
29 matches
Mail list logo
