[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 > tp_next (especially for built-in iterators like > list or dict iterators). Since tp_call 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. _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
