[Python-Dev] Generator methods - "what's next" ?
Hello everyone I'm a little confused by the recent changes to the generator system... I basically agreed with renaming the next() method to __next__(), so as to follow the naming of other similar methods (__iter__() etc.). But I noticed then that all the other methods of the generator had stayed the same (send, throw, close...), which gives really weird (imo) codes : next(it) it.send(35) it.throw(Exception()) next(it) Browsing the web, I've found people troubled by that asymmetry, but no remarks on its causes nor its future... Since __next__(), send() and others have really really close semantics, I consider that state as a python wart, one of the few real ones I can think of. Is there any plan to fix this ? Either by coming back to the next() method, or by putting all the "magical methods" of generators in the __specialattributes__ bag ? next(it) send(it, 5) throw(it, Exception()) ... Thanks a lot for the information, Pascal ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Generator methods - "what's next" ?
Georg Brandl a écrit : Firephoenix schrieb: Hello everyone I'm a little confused by the recent changes to the generator system... I basically agreed with renaming the next() method to __next__(), so as to follow the naming of other similar methods (__iter__() etc.). But I noticed then that all the other methods of the generator had stayed the same (send, throw, close...), which gives really weird (imo) codes : next(it) it.send(35) it.throw(Exception()) next(it) Browsing the web, I've found people troubled by that asymmetry, but no remarks on its causes nor its future... Since __next__(), send() and others have really really close semantics, I consider that state as a python wart, one of the few real ones I can think of. You're missing an important detail: next()/__next__() is a feature of all iterators, while send() and throw() are generator-only methods. The only thing I could imagine is to add a generator.next() method that is simply an alias for generator.__next__(). However, TSBOOWTDI. cheers, Georg Good point indeed. Generator methods (send, throw...) are some kind of black magic compared to normal methods, so I'd find it normal if their naming reflected this specificity, but on the other end it wouldn't be cool to overflow the builtin scope with all the corresponding functions "send(iter, var)"... so I guess all that will stay the way it is. Regards, Pascal ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Generator methods - "what's next" ?
Stephen J. Turnbull a écrit :
Firephoenix writes:
> I'm a little confused by the recent changes to the generator system...
Welcome to the club. It's not easy even for the gurus. See the PEP
380 ("yield from") discussions (mostly on Python-Ideas).
> But I noticed then that all the other methods of the generator had
> stayed the same (send, throw, close...), which gives really weird (imo)
> codes :
>
>next(it)
>it.send(35)
>it.throw(Exception())
>next(it)
>
>
> Browsing the web, I've found people troubled by that asymmetry, but no
> remarks on its causes nor its future...
Well, this kind of discussion generally belongs on c.l.py, but as far
as I know, .next() is still present for generators but it's spelled
.send(None). See PEP 342. It seems to me that the rationale for
respelling .next() as .__next__() given in PEP 3114 doesn't apply to
.send() and .throw(), since there is no syntax which invokes those
methods magically.
Also note that since next() takes no argument, it presumes no
knowledge of the implementation of the iterator. So specification as
a function called "on" the iterator seems natural to me. But .send()
and .throw() are only useful if you know the semantics of their
arguments, ie, the implementation of the generator. Thus using method
syntax for them seems more natural to me.
If you have some concrete suggestions you want to follow up to
Python-Dev with, two remarks:
The code presented above is weird because that code is weird, not
because the generator methods are messed up. Why would you ever write
that code? You need a plausible use case, one where a generator is
the natural way to write the code, but it's not explicitly iterative.
Second, the whole trend is the other direction, fitting generators
naturally into Python syntax without using explicit invocation of
methods. Again, PEP 380 is an example (though rather specialized).
As is the expression form of yield (half-successful in that no
recv() syntax or builtin is needed, although .send() seems to be). So
the use case requested above will need to be compelling.
Whoups, now that you mention it, I discover other mailing-lists seemed
more suitable for this subject... sorry
Actually I ran over an example like the following, in the case of a
"reversed generator" that has to be activated by a first call to "next",
before we're able to send data to the yield expression it has encountered.
But as you mention, send(None) would work as well, and this kind of
"setup operation" had better be hidden in a function decorator or
something like that.
>next(it) # init phase
>it.send(35)
>it.send(36)
Regards,
pascal Chambon
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Generator methods - "what's next" ?
Greg Ewing a écrit : Firephoenix wrote: I basically agreed with renaming the next() method to __next__(), so as to follow the naming of other similar methods (__iter__() etc.). But I noticed then that all the other methods of the generator had stayed the same (send, throw, close...) Keep in mind that next() is part of the iterator protocol that applies to all iterators, whereas the others are specific to generators. By your reasoning, any object that has any __xxx__ methods should have all its other methods turned into __xxx__ methods as well. Indeed, I kind of mixed up generators with the wider family of iterators. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
