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
Firephoenix schrieb:
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 -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
Georg Brandl a écrit :
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
Firephoenix wrote:
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. -- Greg
Firephoenix schrieb:
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 -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
Georg Brandl a écrit :
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
Firephoenix wrote:
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. -- Greg
participants (3)
-
Firephoenix -
Georg Brandl -
Greg Ewing