[Python-3000] PEP: rename it.next() to it.__next__(), add a next() built-in

[Terry Reedy]

<python at rcn.com> wrote in message 
news:20070305123101.BAH59075 at ms09.lnh.mail.rcn.net...
| 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 time?

For generators, I could imagine renaming .next to .__call__, but in 
general, how would you mark something as an iterator (versus non-iterator 
iterable or anything else) without .next (or the proposed .__next__), since 
that is the very thing  that now marks it (along with .__iter__) as an 
iterator.  In other words, what would a user-defined iterator class look 
like?

If you say .__call__ along with .__iter__, then you are stipulating that 
non-iterator iterables cannot be callable themselves.  I have no idea it 
this would break code.

|  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.

No me.  So 'some people' rather than 'people'.  How many?  Learning about 
method binding is fairly important.  Would changing .next to .__call__ 
really solve whatever problem you think there is?

| >>> ### What we do now
| >>> import itertools
| >>> count = itertools.count(1).next
| >>> count()
| 1
| >>> count()
| 2
|
|
| >>> ### What would be nice

But, I believe slower, due to the repeated .__call__ method name lookup

| >>> import itertools
| >>> cnt = itertools.count(1)
| >>> cnt()
| 1
| >>> cnt()
| 2

so I expect the sophisticated user, if expecting to call cnt perhaps 
millions of times, would write

cnt = itertools.count(1).__call__ # or whatever

Bound .next methods are perhaps unique in potentially massive reuse.

Terry Jan Reedy