[Python-3000] PEP: rename it.next() to it.next(), add a next() built-in (original) (raw)
python at rcn.com python at rcn.com
Mon Mar 5 20:26:07 CET 2007
- Previous message: [Python-3000] PEP: rename it.next() to it.__next__(), add a next() built-in
- Next message: [Python-3000] PEP: rename it.next() to it.__next__(), add a next() built-in
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[Raymond]:
Can I suggest that next() and next() be dropped entirely and that iterators just be made callable.
[GvR]
This sounds attractive, except that I fear that the optimizations we've implemented for calling tpnext (especially for built-in iterators like list or dict iterators). Since tpcall must be usable in other contexts, and has much more optional features, it will be hard to carry these optimizations over.
I should mull this over for a bit. It may be possible to keep the tp_iter slot for builtins and have the tp_call slot forward the invocation. That keeps the speed for the C iterators, simplifies the API, and will still be faster than next() because it bypasses the method name lookup.
OTOH, I haven't thought this through and might encounter a roadblock when trying to implement it.
It would also invalidate classes that serve as their own iterator (like files) and already implement call() for sa different purpose.
My thought here is that iterators should always be a separate object -- there is no good reason for dir(iter(myfile)) to expose methods that have nothing to do with iteration. In the case of files, it would not be hard to have a singleton file-iterator object.
my-two-cents,
Raymond
P.S. I have to credit David Mertz with being one of the original proponents of making iterators callable instead of pushing the functionality into the next() method.
- Previous message: [Python-3000] PEP: rename it.next() to it.__next__(), add a next() built-in
- Next message: [Python-3000] PEP: rename it.next() to it.__next__(), add a next() built-in
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]