A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from http://mail.python.org/pipermail/python-dev/2005-June/054267.html below:

[Python-Dev] Withdrawn PEP 288 and thoughts on PEP 342

[Python-Dev] Withdrawn PEP 288 and thoughts on PEP 342 [Python-Dev] Withdrawn PEP 288 and thoughts on PEP 342Raymond Hettinger python at rcn.com
Fri Jun 17 04:26:19 CEST 2005
 [Phillip]
> I could definitely go for dropping __next__ and the next() builtin
from
> PEP
> 342, as they don't do anything extra.  I also personally don't care
about
> the new continue feature, so I could do without for-loop alteration
> too.  I'd be perfectly happy passing arguments to next() explicitly; I
> just
> want yield expressions.

That's progress!  Please do what you can to get the non-essential
changes out of 342.




> >Meanwhile, it hasn't promised any advantages over the dead PEP 288
> >proposals.
> 
> Reading the comments in PEP 288's revision history, it sounds like the
> argument was to postpone implementation of next(arg) and yield
expressions
> to a later version of Python, after more community experience with
> generators.  We've had that experience now.

288 was brought out of retirement a few months ago.  Guido hated every
variation of argument passing and frequently quipped that data passing
was trivially accomplished though mutable arguments to a generator,
through class based iterators, or via a global variable.  I believe all
of those comments were made recently and they all apply equally to 342.


Raymond
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4