Re: [Python-3000] PEP: rename it.next() to it.__next__(), add a next() built-in
Can I suggest that next() and __next__() be dropped entirely and that iterators just be made callable. 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. >>> ### What we do now >>> import itertools >>> count = itertools.count(1).next >>> count() 1 >>> count() 2 >>> ### What would be nice >>> import itertools >>> cnt = itertools.count(1) >>> cnt() 1 >>> cnt() 2 >>> def f(x): ...while x > 1: ...yield x ...if x % 2 == 0: ...x //= 2 ...else: ...x = x * 3 + 1 ... >>> g = f(12) >>> g() 12 >>> g() 6 >>> g() 3 >>> g() 10 Raymond Hettinger ___ 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
Re: [Python-3000] PEP: rename it.next() to it.__next__(), add a next() built-in
[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
Re: [Python-3000] PEP: rename it.next() to it.__next__(), add a next() built-in
[Ka-Ping] > Title: Renaming iterator.next() to iterator.__next__() > == [Josiah] > It sounds and reads just fine, though I'm -1 on the change > if only because 1) it adds a builtin, 2) it renames a > protocol method, making it potentially difficult and/or > buggy to write forward or backward compatible code, > 3) it smells like gratuitous breakage. And, more importantly, it is butt-ugly. Raymond _______ 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
Re: [Python-3000] Possible py3k problem.
On Tue, Nov 18, 2008 at 03:26:32PM -0500, Lambert, David W (S&T) wrote: > > Attached program works with > > callback = GSL_FUNCTION(self.f) > set_with_values(mnzr,callback,xn,fn,xLB,fLB,xUB,fUB) > > But core dumps with > > set_with_values(mnzr,GSL_FUNCTION(self.f),xn,fn,xLB,fLB,xUB,fUB) > > > I do not understand the difference. Must be one of these possibilities: It would be interesting to know if slightly modified first version works too: set_with_values(mnzr,(typeof(callback))GSL_FUNCTION(self.f),xn,fn,xLB,fLB,xUB,fUB) I'm not sure, that it will segfault too. But can't test it on Opteron, sorry for that. To clear out the situation, just want to ask, what is the type of callback variable and how it differs from the type of GSL_FUNCTION(...) expression. _______ 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
