"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 t
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:
>
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 woul
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
Raymond Hettinger wrote:
> This conversation is getting goofy.
indeed.
let's pray that nobody that is considering picking up Python sees this
thread.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-
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
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 _
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
[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
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,
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 - partic
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
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
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 underscor
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 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 rat
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
> someti
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, th
[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
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__(), http://www.python.o
>> -1 on the silly renaming to __next__ and adding __builtin__.next().
>> We have len() because it applies to many different object types.
>> In contrast, next() would apply only to iterables.
[Greg Ewing]
> And you don't think there are many different
> types of iterables?
Um, I meant iterators
21 matches
Mail list logo
