Another nice thing about having a next() built-in is that it makes
getting the first item of a generator expression a lot more elegant,
IMHO.
I think this:
next(item for item in items if item 3)
is a lot clearer than this:
(item for item in items if item 3).next()
or alternatives that would
On 3/6/06, Michael Hoffman [EMAIL PROTECTED] wrote:
Another nice thing about having a next() built-in is that it makes
getting the first item of a generator expression a lot more elegant,
IMHO.
I think this:
next(item for item in items if item 3)
is a lot clearer than this:
(item for
Michael Hoffman [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Another nice thing about having a next() built-in is that it makes
getting the first item of a generator expression a lot more elegant,
I think this:
next(item for item in items if item 3)
is a lot clearer than this:
Raymond Hettinger wrote:
This conversation is getting goofy.
indeed.
let's pray that nobody that is considering picking up Python sees this
thread.
/F
___
Python-Dev mailing list
Python-Dev@python.org
Phillip J. Eby a écrit :
I didn't misstate her argument or reduce it to the absurd. I simply
applied that argument consistently to similar features of Python. It's you
who is concluding that this results in absurdity; I made no such
conclusion. I'm simply pointing out that in 3.0 we
On 3/3/06, Raymond Hettinger [EMAIL PROTECTED] wrote:
[Aahz] * As a writer/teacher, I want to be able to say, All Python special methods have leading and trailing double-underscore.Period, end of story.When teaching your classes, do you sense an aversion to using double underscore
methods in
At 09:34 AM 3/4/2006 -0800, Anna Ravenscroft wrote:
I think this is a really good point. next() is supposed to get used, by
coders, in regular code - so it shouldn't be __next__. I can understand
the desire for both forms, although that seems it would clutter things up
unnecessarily -
On Sat, Mar 04, 2006 at 03:45:03PM -0500, Phillip J. Eby wrote:
At 09:34 AM 3/4/2006 -0800, Anna Ravenscroft wrote:
I think this is a really good point. next() is supposed to get used, by
coders, in regular code - so it shouldn't be __next__. I can understand
the desire for both forms,
[Anna Ravenscroft]
I think this is a really good point. next() is supposed to get used, by
coders, in regular code - so it shouldn't be __next__. I can understand the
desire for both forms, although that seems it would clutter things up
unnecessarily - particularly if the two do the same thing.
At 04:11 PM 3/4/2006 -0500, Raymond Hettinger wrote:
[Anna Ravenscroft]
I think this is a really good point. next() is supposed to get used, by
coders, in regular code - so it shouldn't be __next__. I can understand
the desire for both forms, although that seems it would clutter things
up
At 12:05 AM 3/5/2006 +0300, Oleg Broytmann wrote:
On Sat, Mar 04, 2006 at 03:45:03PM -0500, Phillip J. Eby wrote:
At 09:34 AM 3/4/2006 -0800, Anna Ravenscroft wrote:
I think this is a really good point. next() is supposed to get used, by
coders, in regular code - so it shouldn't be __next__.
At 04:44 PM 3/4/2006 -0500, Raymond Hettinger wrote:
As far as I can understand your position, you seem to be arguing that
whatever we have now is correct, and therefore changing it would be wrong.
Yes, that's pretty much it. IMO, introducing __builtin__.next() would
suck. The sublime
On Wed, Mar 01, 2006, Raymond Hettinger wrote:
I usually let this sort of thing slide, but the iterator API is too
important for trivial, incompatible, and damaging changes. Looking
back at Guido's original rationale for naming the method next()
instead of __next__(),
[Aahz]
* As a writer/teacher, I want to be able to say, All Python special
methods have leading and trailing double-underscore. Period, end of
story.
When teaching your classes, do you sense an aversion to using double underscore
methods in regular code? I sense an implied message that
Raymond writes:
The double underscore convention is appropriate where the method is always
invoked magically in normal code and not called directly. The next() method
is
differenct because it is a mixed case, sometimes called magically and
sometimes
called directly. In the latter case, the
On 3/3/06, Raymond Hettinger [EMAIL PROTECTED] wrote:
The double underscore convention is appropriate where the method is always
invoked magically in normal code and not called directly. The next() method
is
differenct because it is a mixed case, sometimes called magically and
sometimes
On Fri, 2006-03-03 at 13:06 -0800, Michael Chermside wrote:
I think it's clear that if a method is invoked magically, it ought to have
underscores; if it is invoked directly then it ought not to. next() is
invoked both ways, so the question is which of the following invariants
we would rather
At 04:09 PM 3/3/2006 -0500, Jeremy Hylton wrote:
I think it is a little odd that next is not spelled __next__, but I
appreciate the reasons given here in particular. Every time I right
.next(), I'm happy that it doesn't have underscores.
But then next(ob) should make you even happier, because
On 3/3/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 04:09 PM 3/3/2006 -0500, Jeremy Hylton wrote:
I think it is a little odd that next is not spelled __next__, but I
appreciate the reasons given here in particular. Every time I right
.next(), I'm happy that it doesn't have underscores.
Raymond Hettinger wrote:
When teaching your classes, do you sense an aversion to using double
underscore methods in regular code? I sense an implied message that
these methods are not intended to be called directly (i.e. the discomfort
of typing x.__setitem__(k,v) serves as a cue to write
20 matches
Mail list logo
