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*
[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
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
[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
[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
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
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
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
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
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
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
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
12 matches
Mail list logo
