[Python-Dev] Breaking off Enhanced Iterators PEP from PEP 340
On 5/6/05, Paul Moore [EMAIL PROTECTED] wrote: I don't think it damages any features. Are there features you still think the non-looping proposal removes? (I'm not counting orthogonal feautres like continue EXPR which could easily be added as an entirely separate PEP.) I *am* specifically referring to these orthogonal features. Removal of looping by modification of PEP 340 will do no such damage, I agree - but removal by accepting an updated PEP 310, or a new PEP, *will* (unless the entirely separate PEP you mention is written and accepted along with the non-looping PEP - and I don't think that will happen). So, just to make sure, if we had another PEP that contained from PEP 340[1]: * Specification: the __next__() Method * Specification: the next() Built-in Function * Specification: a Change to the 'for' Loop * Specification: the Extended 'continue' Statement * the yield-expression part of Specification: Generator Exit Handling would that cover all the pieces you're concerned about? I'd be willing to break these off into a separate PEP if people think it's a good idea. I've seen very few complaints about any of these pieces of the proposal. If possible, I'd like to see these things approved now, so that the discussion could focus more directly on the block-statement issues. STeVe [1] http://www.python.org/peps/pep-0340.html -- You can wordify anything if you just verb it. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Breaking off Enhanced Iterators PEP from PEP 340
[Steven Bethard] So, just to make sure, if we had another PEP that contained from PEP 340[1]: * Specification: the __next__() Method * Specification: the next() Built-in Function * Specification: a Change to the 'for' Loop * Specification: the Extended 'continue' Statement * the yield-expression part of Specification: Generator Exit Handling would that cover all the pieces you're concerned about? I'd be willing to break these off into a separate PEP if people think it's a good idea. I've seen very few complaints about any of these pieces of the proposal. If possible, I'd like to see these things approved now, so that the discussion could focus more directly on the block-statement issues. I don't think it's necessary to separate this out into a separate PEP; that just seems busy-work. I agree these parts are orthogonal and uncontroversial; a counter-PEP can suffice by stating that it's not countering those items nor repeating them. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Breaking off Enhanced Iterators PEP from PEP 340
I'd be willing to break these off into a separate PEP if people think it's a good idea. I've seen very few complaints about any of these pieces of the proposal. If possible, I'd like to see these things approved now, so that the discussion could focus more directly on the block-statement issues. I don't think it's necessary to separate this out into a separate PEP; that just seems busy-work. I agree these parts are orthogonal and uncontroversial; a counter-PEP can suffice by stating that it's not countering those items nor repeating them. If someone volunteers to split it out for you, I think it would be worthwhile. Right now, the PEP is hard to swallow in one bite. Improving its digestibility would be a big help when the PEP is offered up to the tender mercies to comp.lang.python. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Breaking off Enhanced Iterators PEP from PEP 340
[me] I don't think it's necessary to separate this out into a separate PEP; that just seems busy-work. I agree these parts are orthogonal and uncontroversial; a counter-PEP can suffice by stating that it's not countering those items nor repeating them. [Raymond] If someone volunteers to split it out for you, I think it would be worthwhile. Right now, the PEP is hard to swallow in one bite. Improving its digestibility would be a big help when the PEP is offered up to the tender mercies to comp.lang.python. Well, I don't care so much about their tender mercies right now. I'm not even sure that if we reach agreement on python-dev there's any point in repeating the agony on c.l.py. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Breaking off Enhanced Iterators PEP from PEP 340
[Guido] I don't think it's necessary to separate this out into a separate PEP; that just seems busy-work. I agree these parts are orthogonal and uncontroversial; a counter-PEP can suffice by stating that it's not countering those items nor repeating them. [Raymond] If someone volunteers to split it out for you, I think it would be worthwhile. Right now, the PEP is hard to swallow in one bite. Improving its digestibility would be a big help when the PEP is offered up to the tender mercies to comp.lang.python. Well, busy-work or not, I took the 20 minutes to split them up, so I figured I might as well make them available. It was actually really easy to split them apart, and I think they both read better this way, but I'm not sure my opinion counts for much here anyway. ;-) (The Enhanced Iterators PEP is first, the remainder of PEP 340 follows it.) -- PEP: XXX Title: Enhanced Iterators Version: Last-Modified: Author: Guido van Rossum Status: Draft Type: Standards Track Content-Type: text/plain Created: 6-May-2005 Post-History: Introduction This PEP proposes a new iterator API that allows values to be passed into an iterator using continue EXPR. These values are received in the iterator as an argument to the new __next__ method, and can be accessed in a generator with a yield-expression. The content of this PEP is derived from the original content of PEP 340, broken off into its own PEP as the new iterator API is pretty much orthogonal from the anonymous block statement discussion. Motivation and Summary ... Use Cases See the Examples section near the end. Specification: the __next__() Method A new method for iterators is proposed, called __next__(). It takes one optional argument, which defaults to None. Calling the __next__() method without argument or with None is equivalent to using the old iterator API, next(). For backwards compatibility, it is recommended that iterators also implement a next() method as an alias for calling the __next__() method without an argument. The argument to the __next__() method may be used by the iterator as a hint on what to do next. Specification: the next() Built-in Function This is a built-in function defined as follows: def next(itr, arg=None): nxt = getattr(itr, __next__, None) if nxt is not None: return nxt(arg) if arg is None: return itr.next() raise TypeError(next() with arg for old-style iterator) This function is proposed because there is often a need to call the next() method outside a for-loop; the new API, and the backwards compatibility code, is too ugly to have to repeat in user code. Specification: a Change to the 'for' Loop A small change in the translation of the for-loop is proposed. The statement for VAR1 in EXPR1: BLOCK1 else: BLOCK2 will be translated as follows: itr = iter(EXPR1) arg = None# Set by continue EXPR2, see below brk = False while True: try: VAR1 = next(itr, arg) except StopIteration: brk = True break arg = None BLOCK1 if brk: BLOCK2 (However, the variables 'itr' etc. are not user-visible and the built-in names used cannot be overridden by the user.) Specification: the Extended 'continue' Statement In the translation of the for-loop, inside BLOCK1, the new syntax continue EXPR2 is legal and is translated into arg = EXPR2 continue (Where 'arg' references the corresponding hidden variable from the previous section.) This is also the case in the body of the block-statement proposed below. EXPR2 may contain commas; continue 1, 2, 3 is equivalent to continue (1, 2, 3). Specification: Generators and Yield-Expressions Generators will implement the new __next__() method API, as well as the old argument-less next() method which becomes an alias for calling __next__() without an argument. The yield-statement will be allowed to be used on the right-hand side of an assignment; in that case it is referred to as yield-expression. The value of this yield-expression is None unless __next__() was called with an argument; see below. A yield-expression must always be parenthesized except when it occurs at the top-level expression on the right-hand side of an assignment. So x = yield 42 x = yield x = 12 + (yield 42) x = 12 + (yield) foo(yield 42) foo(yield) are all legal, but x = 12 + yield 42 x = 12 + yield foo(yield 42, 12) foo(yield, 12) are all illegal. (Some of
Re: [Python-Dev] Breaking off Enhanced Iterators PEP from PEP 340
On 5/6/05, Steven Bethard [EMAIL PROTECTED] wrote: Well, busy-work or not, I took the 20 minutes to split them up, so I figured I might as well make them available. It was actually really easy to split them apart, and I think they both read better this way, but I'm not sure my opinion counts for much here anyway. ;-) (The Enhanced Iterators PEP is first, the remainder of PEP 340 follows it.) Thanks for doing this. I think you may well be right - the two pieces feel more orthogonal like this (I haven't checked for dependencies, I'm trusting your editing and Guido's original assertion that the parts are independent). -- PEP: XXX Title: Enhanced Iterators Strawman question - as this is the uncontroversial bit, can this part be accepted as it stands? :-) Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Breaking off Enhanced Iterators PEP from PEP 340
On 5/6/05, Paul Moore [EMAIL PROTECTED] wrote: On 5/6/05, Steven Bethard [EMAIL PROTECTED] wrote: PEP: XXX Title: Enhanced Iterators Strawman question - as this is the uncontroversial bit, can this part be accepted as it stands? :-) FWIW, I'm +1 on this. Enhanced Iterators * updates the iterator protocol to use .__next__() instead of .next() * introduces a new builtin next() * allows continue-statements to pass values to iterators * allows generators to receive values with a yield-expression The first two are, I believe, how the iterator protocol probably should have been in the first place. The second two provide a simple way of passing values to generators, something I got the impression that the co-routiney people would like a lot. STeVe -- You can wordify anything if you just verb it. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Breaking off Enhanced Iterators PEP from PEP 340
Enhanced Iterators: ... When the *initial* call to __next__() receives an argument that is not None, TypeError is raised; this is likely caused by some logic error. This made sense when the (Block) Iterators were Resources, and the first __next__() was just to trigger the setup. It makes less sense for general iterators. It is true that the first call in a generic for-loop couldn't pass a value (as it isn't continued), but I don't see anything wrong with explicit calls to __next__. Example: An agent which responds to the environment; the agent can execute multi-stage plans, or change its mind part way through. action = scheduler.__next__(current_sensory_input) -jJ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Breaking off Enhanced Iterators PEP from PEP 340
Enhanced Iterators: ... When the *initial* call to __next__() receives an argument that is not None, TypeError is raised; this is likely caused by some logic error. [Jim Jewett] This made sense when the (Block) Iterators were Resources, and the first __next__() was just to trigger the setup. It makes less sense for general iterators. It is true that the first call in a generic for-loop couldn't pass a value (as it isn't continued), but I don't see anything wrong with explicit calls to __next__. Example: An agent which responds to the environment; the agent can execute multi-stage plans, or change its mind part way through. action = scheduler.__next__(current_sensory_input) Good point. I'd be happy if the requirement that the first __next__() call doesn't have an argument (or that it's None) only applies to generators, and not to iterators in general. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Breaking off Enhanced Iterators PEP from PEP 340
On Fri, 6 May 2005, Guido van Rossum wrote: There's one alternative possible (still orthogonal to PEP 340): instead of __next__(), we could add an optional argument to the next() method, and forget about the next() built-in. I prefer your original proposal. I think this is a good time to switch to next(). If we are going to change the protocol, let's do it right. -- ?!ng ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Breaking off Enhanced Iterators PEP from PEP 340
Guido van Rossum wrote: [SNIP] There's one alternative possible (still orthogonal to PEP 340): instead of __next__(), we could add an optional argument to the next() method, and forget about the next() built-in. This is more compatible (if less future-proof). Old iterators would raise an exception when their next() is called with an argument, and this would be a reasonable way to find out that you're using continue EXPR with an iterator that doesn't support it. (The C level API would be a bit hairier but it can all be done in a compatible way.) I prefer the original proposal. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Breaking off Enhanced Iterators PEP from PEP 340
On 5/6/05, Steven Bethard [EMAIL PROTECTED] wrote:
FWIW, I'm +1 on this. Enhanced Iterators
* updates the iterator protocol to use .__next__() instead of .next()
* introduces a new builtin next()
* allows continue-statements to pass values to iterators
* allows generators to receive values with a yield-expression
The first two are, I believe, how the iterator protocol probably
should have been in the first place. The second two provide a simple
way of passing values to generators, something I got the impression
that the co-routiney people would like a lot.
Thank you for splitting the PEP. Conceptually, the coroutine part
has nothing to do with blocks and it stands on its own, it is right
to discuss it separately from the block syntax.
Personally, I do not see an urgent need for the block syntax (most of
the use case can be managed with decorators) nor for the couroutine
syntax (you can already use Armin Rigo's greenlets for that).
Anyway, the idea of passing arguments to generators is pretty cool,
here is some code I have, adapted from Armin's presentation at the
ACCU conference:
from py.magic import greenlet
def yield_(*args):
return greenlet.getcurrent().parent.switch(*args)
def send(key):
return process_commands.switch(key)
@greenlet
def process_commands():
while True:
line = ''
while not line.endswith('\n'):
line += yield_()
print line,
if line == 'quit\n':
print are you sure?
if yield_() == 'y':
break
process_commands.switch() # start the greenlet
send(h)
send(e)
send(l)
send(l)
send(o)
send(\n)
send(q)
send(u)
send(i)
send(t)
send(\n)
Michele Simionato
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
