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
Hi,
On 10/08/2013 14:23, Michael Woerister wrote:
Hi everyone,
I'm writing a series of blog posts about a possible *yield statement*
for Rust. I just published the article that warrants some discussion and
I'd really like to hear what you all think about the things therein:
Hello,
I cannot comment on the difficulty of implementation, however I can only
join Armin in wishing that if it ever takes off it would be better to make
the declaration explicit rather than having to parse the definition of the
function to suddenly realize that this is not a simple function but
Note that we have an issue open in the bug tracker for this:
https://github.com/mozilla/rust/issues/7746
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
On 11.08.2013 12:01, Armin Ronacher wrote:
The way yield return works in C# is that it rewrites the code into a
state machine behind the scenes. It essentially generates a helper
class that encapsulates all the state.
In Rust that's much harder to do due to the type system. Imagine you
are
On 11.08.2013 12:31, Matthieu Monrocq wrote:
I cannot comment on the difficulty of implementation, however I can
only join Armin in wishing that if it ever takes off it would be
better to make the declaration explicit rather than having to parse
the definition of the function to suddenly
Hi,
On 11/08/2013 15:43, Michael Woerister wrote:
Maybe you do now :)
I see where this is going, that's actually not too bad. So essentially
it would generate some anonymous struct and impl.
Can you elaborate on what you mean by both directions?
Python has this inheritance tree (virtual):
Hi,
On 11/08/2013 16:18, Armin Ronacher wrote:
Yes, in theory you could make a function that returns nil but is
declared as returning an iterator, just return the empty iterator for
that type, but that seems wrong.
In addition to that does yield fn do a step towards solving the
confusion that
I've opened a pull request for basic runtimeless support on libstd:
https://github.com/mozilla/rust/pull/8454
I think it needs a wider discussion. I think it's very desirable to
have a libstd that can be used without a runtime, especially once we
have static linking and link-time DCE. As it
Hi,
[...] The reason I'm bringing this up is because in case Rust ever
wants to gain support for bidirectional generators it should from the
very start have something like a yield from to not break the reverse
forwarding.
Thanks for the extensive explanation. These iterators with
Hi Corey,
It's great to see that people are thinking more and more about integrating
Rust in existing languages!
I wonder however whether the other alternative has been envisioned: if Rust
requires a runtime to work properly (specifically: TLS, task failure),
would it be possible to provide an
On Sun, Aug 11, 2013 at 3:15 PM, Matthieu Monrocq
matthieu.monr...@gmail.com wrote:
Hi Corey,
It's great to see that people are thinking more and more about integrating
Rust in existing languages!
I didn't even consider that aspect of it tbh; I was only thinking of
bare-metal Rust.
I
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
So I came across a weird fact that is entirely inconsistent with my
mental model of Rust. extra::arc::RWArc is private, but you can use it
*everywhere*. You can call RWArc::new, you can use it as a type, etc.
What is happening?
___
Rust-dev mailing list
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.
___
I wonder if Rust could do something along the lines of F# computation
expressions http://msdn.microsoft.com/en-us/library/dd233182.aspx (or
Haskell's do-notation, if one is so inclined). This approach would put
more strain on the optimizer, which would have to deal with all those
lambda
Is it `pub use`d elsewhere? That would be my first thought (can't check now as
I'm away from a computer).
-Kevin Ballard
On Aug 11, 2013, at 4:44 PM, Corey Richardson co...@octayn.net wrote:
So I came across a weird fact that is entirely inconsistent with my
mental model of Rust.
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
Nope :(
On Sun, Aug 11, 2013 at 6:12 PM, Kevin Ballard ke...@sb.org wrote:
Is it `pub use`d elsewhere? That would be my first thought (can't check now
as I'm away from a computer).
-Kevin Ballard
On Aug 11, 2013, at 4:44 PM, Corey Richardson co...@octayn.net wrote:
So I came across a
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
On 8/12/13 10:12 AM, Kevin Ballard wrote:
So I came across a weird fact that is entirely inconsistent with my
mental model of Rust. extra::arc::RWArc is private, but you can use it
*everywhere*. You can call RWArc::new, you can use it as a type, etc.
What is happening?
This is a known bug, and
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
So in general, using std I/O from outside of tasks is going to continue to be
sketchy for quite a while.
Thanks for the info, unfortunate though it may be. Given this, it doesn't look
like I should bother even trying to get anything to work with the high level
FUSE API providing its own
32 matches
Mail list logo
