[Steven Bethard]
> 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
On May 7, 2005, at 1:45 AM, Michele Simionato wrote:
> 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-stat
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 receiv
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 ex
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 sw
At 01:18 PM 5/6/2005 -0700, 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. This is more compatible
>(if less future-proof). Old iterators
> 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 t
On 5/6/05, Steven Bethard <[EMAIL PROTECTED]> wrote:
> 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 acce
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 make
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
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 co
[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
[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 volunt
> > 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
> > bloc
[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 yi
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.)
>
>
16 matches
Mail list logo
