"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> Since next() is equivalent to send(None) we don't really need the
> next() method do we?
As long as its renamed to __next__, then we seemingly wouldn't need next,
though users needing to use next(X) or X.send(None) instead of X.next(),
may be confus
On 3/7/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Since next() is equivalent to send(None) we don't really need the
> next() method do we?
>
Guess not, especially if we make send() default to sending None back.
-Brett
> On 3/7/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > On 3/7/07, Geo
Since next() is equivalent to send(None) we don't really need the
next() method do we?
On 3/7/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On 3/7/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> > Ka-Ping Yee schrieb:
> > > On Wed, 7 Mar 2007, Georg Brandl wrote:
> > >> Ka-Ping Yee schrieb:
> > >> >
On 3/7/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Ka-Ping Yee schrieb:
> > On Wed, 7 Mar 2007, Georg Brandl wrote:
> >> Ka-Ping Yee schrieb:
> >> > On Tue, 6 Mar 2007, Guido van Rossum wrote:
> >> >> Having now read this entire thread I am going to accept Ping's PEP.
> >> >> Adding the sentinel
Ka-Ping Yee schrieb:
> On Wed, 7 Mar 2007, Georg Brandl wrote:
>> Ka-Ping Yee schrieb:
>> > On Tue, 6 Mar 2007, Guido van Rossum wrote:
>> >> Having now read this entire thread I am going to accept Ping's PEP.
>> >> Adding the sentinel argument to the next() builtin was what did it for
>> >> me: it
On Wed, 7 Mar 2007, Georg Brandl wrote:
> Ka-Ping Yee schrieb:
> > On Tue, 6 Mar 2007, Guido van Rossum wrote:
> >> Having now read this entire thread I am going to accept Ping's PEP.
> >> Adding the sentinel argument to the next() builtin was what did it for
> >> me: it neatly solves the problem i
Ka-Ping Yee schrieb:
> On Tue, 6 Mar 2007, Guido van Rossum wrote:
>> Having now read this entire thread I am going to accept Ping's PEP.
>> Adding the sentinel argument to the next() builtin was what did it for
>> me: it neatly solves the problem if having to catch that StopIteration
>> in 99% of
Ka-Ping Yee wrote:
> Okay, this is checked in as PEP 3114.
Not 3456? :-(
--
Greg
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/ar
On Tue, 6 Mar 2007, Guido van Rossum wrote:
> Having now read this entire thread I am going to accept Ping's PEP.
> Adding the sentinel argument to the next() builtin was what did it for
> me: it neatly solves the problem if having to catch that StopIteration
> in 99% of the cases.
Okay, this is c
On 3/6/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On 3/6/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> > Guido van Rossum schrieb:
> > > Having now read this entire thread I am going to accept Ping's PEP.
> > > Adding the sentinel argument to the next() builtin was what did it for
> > > me: it n
On 3/6/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> http://docs.python.org/dev/api/type-structs.html#l2h-1017 doesn't say
> that a NULL return can be used as a signal that iterator is exhausted
> without raising StopIteration. That would mean the above could be
> simplified somewhat in terms of r
On 3/6/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Guido van Rossum schrieb:
> > Having now read this entire thread I am going to accept Ping's PEP.
> > Adding the sentinel argument to the next() builtin was what did it for
> > me: it neatly solves the problem if having to catch that StopIteratio
Guido van Rossum schrieb:
Having now read this entire thread I am going to accept Ping's PEP.
Adding the sentinel argument to the next() builtin was what did it for
me: it neatly solves the problem if having to catch that StopIteration
in 99% of the cases.
Attached is a possible implementation
I don't see much point of adding the builtin if we don't rename the
method to __next__, since that would just make the wart stick out
more. The conversion pain is a one-time cost. We can work with 2to3
and Python 2.6 warnings on the conversions. Hey, if we can "from
__future__ import dict_views" th
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> Having now read this entire thread I am going to accept Ping's PEP.
> Adding the sentinel argument to the next() builtin was what did it for
> me: it neatly solves the problem if having to catch that StopIteration
> in 99% of the cases.
Have you rea
Having now read this entire thread I am going to accept Ping's PEP.
Adding the sentinel argument to the next() builtin was what did it for
me: it neatly solves the problem if having to catch that StopIteration
in 99% of the cases.
Thanks all for the discussion!
--Guido
On 3/6/07, Guido van Rossu
On 3/5/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Ka-Ping Yee wrote:
>
> > Just like getattr, two-argument next(iter, sentinel)
> > returns sentinel if StopException is caught.
>
> +1. I've written a number of pieces of code where this
> would have made things neater. Just about any place
On 3/5/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> On 3/5/07, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> [snip]
> > Transition Plan
> > ===
> >
> > Two additional transformations will be added to the 2to3 translation
> > tool [2]_:
> >
> > * Method definitions named ``next`` will be
On 3/5/07, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> In fact, your example was specifically anticipated and addressed in
> the PEP draft I posted here. file.read() is not invoked by a language
> construct. When file.read() gets called, it is because the calling
> code has an explicit call to read(
On 3/6/07, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
On Tue, 6 Mar 2007, Neil Schemenauer wrote:
> The argument that all "protocol" methods should have double
> underscore names seems to be pretty weak too. It's only an appeal
> for consistency, I think. We don't suggest that file-like objects
>
Greg Ewing schrieb:
> I'm -0.7. Classifying next() as an operator doesn't
> seem right -- what "operator" does it correspond to?
>
> Unlike all the other functions in the operator
> module, there is no piece of syntax that corresponds
> directly to what next() would do.
Not all of them. operator
On 3/5/07, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> On Tue, 6 Mar 2007, Neil Schemenauer wrote:
> > We don't suggest that file-like objects
> > should implement __read__() instead of read(), for example.
>
> There is a convention and it is applied quite consistently:
>
> Double-underscores are
On Mon, 5 Mar 2007, Greg Falcon wrote:
> I agree that file.read() is a different beast than iter.next().
> However, file.write() is a counterexample to your argument here. It
> gets called by Python syntax, and yet doesn't (and shouldn't) have
> double underscores.
>
> >>> print >> object(), "foo"
On Tue, 6 Mar 2007, Neil Schemenauer wrote:
> The argument that all "protocol" methods should have double
> underscore names seems to be pretty weak too. It's only an appeal
> for consistency, I think. We don't suggest that file-like objects
> should implement __read__() instead of read(), for ex
Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> This is exactly why the iterator protocol method should be named
> __next__: so it can't collide with method names used for other
> purposes.
And yet people are suggesting that __call__ be used instead of
__next__. If people believe iterators should be sep
Josiah Carlson wrote:
> It's already spelled...
>
> for item in iter:
> #code for when we got something
> break
> else:
> #code for when we didn't get anything
Technically this is true, but I can't help feeling
that's a terribly obscure way to use a for-loop.
Norm
Aahz wrote:
> I'm +0 on operator.next() relative to builtin next().
I'm -0.7. Classifying next() as an operator doesn't
seem right -- what "operator" does it correspond to?
Unlike all the other functions in the operator
module, there is no piece of syntax that corresponds
directly to what next()
Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> Georg Brandl wrote:
>
> > Indeed, you almost always have to have a try-except StopIteration-
> > wrapper around "manual" calls to .next().
The use-cases would likely be analagous to the .find() vs. .index()
methods on strings.
Then again, while I prefe
On Mon, Mar 05, 2007, Ka-Ping Yee wrote:
>
> Abstract
>
>
> The iterator protocol in Python 2.x consists of two methods:
> ``__iter__()`` called on an iterable object to yield an iterator, and
> ``next()`` called on an iterator object to yield the next item in the
> sequence. Using a ``f
Josiah Carlson wrote:
> I have written methods named 'next' which have *nothing* to do
> with the iterator protocol.
That would be another reason for renaming .next() to
.__next__() -- to avoid intruding on the user's
namespace.
--
Greg
___
Python-3000
Georg Brandl wrote:
> Indeed, you almost always have to have a try-except StopIteration-
> wrapper around "manual" calls to .next().
An alternative way of addressing this would be to
have a new control structure. We already have the
'for' statement for when you want all the values;
why not anothe
Ka-Ping Yee wrote:
> PEP 234 (it amuses me that the PEP number for iterators is
> three digits in arithmetic sequence)
I guess the equivalent PEP for Py3k should be
numbered PEP 3456 then. :-)
--
Greg
___
Python-3000 mailing list
Python-3000@python.org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 5, 2007, at 5:45 PM, Greg Ewing wrote:
> Ka-Ping Yee wrote:
>
>> Just like getattr, two-argument next(iter, sentinel)
>> returns sentinel if StopException is caught.
>
> +1. I've written a number of pieces of code where this
> would hav
On Mon, 5 Mar 2007, Josiah Carlson wrote:
> "Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> > On 3/5/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> However, I have written methods named 'next' which have *nothing* to do
> with the iterator protocol.
This is exactly why the iterator protocol metho
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> On 3/5/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > because [...] 2) it renames a protocol method, making it
> > potentially difficult and/or buggy to write forward or backward
> > compatible code, [...]
>
> Did you see my slides and/or video o
<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Can I suggest that next() and __next__() be dropped entirely and that
iterators just be made callable.
Can you do that without making the call a regular, slow call each time?
Or at least without adding a lookup of '__call__' each tim
Greg Ewing schrieb:
> Ka-Ping Yee wrote:
>
>> Just like getattr, two-argument next(iter, sentinel)
>> returns sentinel if StopException is caught.
>
> +1. I've written a number of pieces of code where this
> would have made things neater. Just about any place
> where I've used .next() exp
Ka-Ping Yee wrote:
> Just like getattr, two-argument next(iter, sentinel)
> returns sentinel if StopException is caught.
+1. I've written a number of pieces of code where this
would have made things neater. Just about any place
where I've used .next() explicitly, in fact -- it
always seem
On Mon, 5 Mar 2007 [EMAIL PROTECTED] wrote:
> And, more importantly, it is butt-ugly.
What part exactly? Does this bother you:
def __next__(self):
...
or this:
while whatever:
x = next(i)
...
They look pretty much like the rest of Python to me.
-- ?!ng
__
On Mon, 5 Mar 2007 [EMAIL PROTECTED] wrote:
> Can I suggest that next() and __next__() be dropped entirely
> and that iterators just be made callable.
We went through a long discussion about this when iterators
were being figured out the first time around -- in fact, using
__call__ was the origina
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 5, 2007, at 5:16 PM, Greg Ewing wrote:
> Also I'm not sure I like this idea. It smells like
> an abuse of the notion of calling to me. One doesn't
> normally expect that calling a callable object has
> a side effect on the callable itself.
Per
Barry Warsaw wrote:
> OTOH, making iterators callable as equivalent to .next() as I think
> Raymond suggested sounds about perfect. You get __next__(), plus
> explicit iteration with no additional built in necessary.
But that would raise the question of why __next__
wasn't called __call__ in
On 3/5/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> My thought here is that iterators should always be a separate object -- there
> is no good reason for dir(iter(myfile)) to expose methods that have nothing
> to do with iteration. In the case of files, it would not be hard to have a
> si
On 3/5/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> because [...] 2) it renames a protocol method, making it
> potentially difficult and/or buggy to write forward or backward
> compatible code, [...]
Did you see my slides and/or video of my talk about Py3k yet? This
change can be carried out au
At 10:48 AM 3/5/2007 -0800, Guido van Rossum wrote:
>I fear that the optimizations
>we've implemented for calling tp_next (especially for built-in
>iterators like list or dict iterators). Since tp_call must be usable
>in other contexts, and has much more optional features, it will be
>hard to carry
[Ka-Ping]
> Title: Renaming iterator.next() to iterator.__next__()
> ==
[Josiah]
> It sounds and reads just fine, though I'm -1 on the change
> if only because 1) it adds a builtin, 2) it renames a
> protocol method, making it potentially diffic
[Raymond]:
> Can I suggest that next() and __next__() be dropped entirely
> and that iterators just be made callable.
[GvR]
> This sounds attractive, except that I fear that
> the optimizations we've implemented for calling
> tp_next (especially for built-in iterators like
> list or dict itera
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 5, 2007, at 2:07 PM, Ka-Ping Yee wrote:
> One possibility for making a next() built-in more useful:
>
> Just like getattr, two-argument next(iter, sentinel)
> returns sentinel if StopException is caught.
>
> If you've used .next() expli
One possibility for making a next() built-in more useful:
Just like getattr, two-argument next(iter, sentinel)
returns sentinel if StopException is caught.
If you've used .next() explicitly, would this be handy?
(Or, what convenience would you want in a next() builtin?)
-- ?!ng
___
Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
>
> At Guido's prompting, I drafted the following PEP. How does it sound?
>
> Title: Renaming iterator.next() to iterator.__next__()
> ==
It sounds and reads just fine, though I'm -1 on the change if onl
On 3/5/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> As an alternative, I propose that object grows a .next() method,
> which calls __next__ by default.
This would seem slated to confuse users; they will attempt to
implement next() instead of __next__(). Or people would attempt to
override th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 5, 2007, at 1:36 PM, Martin v. Löwis wrote:
> -1. I dislike the introduction of more builtins unless they have a
> true
> generality (i.e. are likely to be needed in many programs). For this
> one, I think the normal usage of __next__ will be
Ka-Ping Yee schrieb:
> The iterator protocol in Python 2.x consists of two methods:
> ``__iter__()`` called on an iterable object to yield an iterator, and
> ``next()`` called on an iterator object to yield the next item in the
> sequence. Using a ``for`` loop to iterate over an iterable object
>
Can I suggest that next() and __next__() be dropped entirely and that
iterators just be made callable. The current approach seems to make people
think there is something wrong with using an iterator directly (inside of in a
for-loop or function that consumes an iterator.
>>> ### What we do no
On 3/5/07, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
[snip]
> Transition Plan
> ===
>
> Two additional transformations will be added to the 2to3 translation
> tool [2]_:
>
> * Method definitions named ``next`` will be renamed to ``__next__``.
>
> * Explicit calls to the ``next`` method
At Guido's prompting, I drafted the following PEP. How does it sound?
-- ?!ng
Title: Renaming iterator.next() to iterator.__next__()
==
Abstract
The iterator protocol in Python 2.x consists of two methods:
``__iter__()`` called on
56 matches
Mail list logo
