[issue2719] Backport next()

Georg Brandl <[EMAIL PROTECTED]> added the comment: Updated and committed as r62599. Also fixed your nits in the original 3k version in r62598. -- status: open -> closed __ Tracker <[EMAIL PROTECTED]> ___

[issue2719] Backport next()

Guido van Rossum <[EMAIL PROTECTED]> added the comment: Feel free to submit a patch to fix the docs. Changing the API is not an option -- it's been like this since the tp_iternext slot was added, and it's been designed like this for a reason: so that in the common case of iterating over a built-

[issue2719] Backport next()

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment: On Wed, Apr 30, 2008 at 12:41 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > the iternext slot is designed to return NULL without setting an > exception. This is not what the documentation says: """ iternextfunc PyTypeObject.tp_ite

[issue2719] Backport next()

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment: On Wed, Apr 30, 2008 at 12:41 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > Guido van Rossum <[EMAIL PROTECTED]> added the comment: > > > .. builtin_next() should return > > NULL without an exception set and thus trigger a Syst

[issue2719] Backport next()

Guido van Rossum <[EMAIL PROTECTED]> added the comment: +1 on this. I have a few nits about the code: Line 1083: "%.200s object is not an iterator", it->ob_type->tp_name); Line is too long. Line 1088: if (res == NULL) { How about if (res != NULL) return res; ? Line 1089: if (def) { if

[issue2719] Backport next()

Guido van Rossum <[EMAIL PROTECTED]> added the comment: > I would think tp_iternext failing to set an exception should not be > translated into stop iteration. Instead, builtin_next() should return > NULL without an exception set and thus trigger a SystemError. Wrong; the iternext slot is des

[issue2719] Backport next()

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment: One more question: What is the rationale for + res = (*it->ob_type->tp_iternext)(it); + if (res == NULL) { .. + PyErr_SetNone(PyExc_StopIteration); + return NULL; ? I would think

[issue2719] Backport next()

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment: I thought new code is supposed to use Py_TYPE macro instead of ->ob_type: + "%.200s object is not an iterator", it->ob_type- >tp_name); .. + res = (*it->ob_type->tp_iternext)(it); Py3k branch has the same is

[issue2719] Backport next()

Guido van Rossum <[EMAIL PROTECTED]> added the comment: I think it's important to make this available in 2.6; it will let people writing 3.0-oriented code in 2.6 (as several developers are planning to do) do the right thing for this syntax. __ Tracker <[EMAIL PROT

[issue2719] Backport next()

Raymond Hettinger <[EMAIL PROTECTED]> added the comment: The problem is with the "if you use it consistently" premise. That will not hold in an environment with legacy code, multiple programmers, lots of code in ASPN recipes and published materials, and third-party modules. A patch like this

[issue2719] Backport next()

Georg Brandl <[EMAIL PROTECTED]> added the comment: IMO having next() in 2.6 helps since if you use it consistently you don't have to care about calling .next() or .__next__(). Also, I don't see how this is different from having e.g. reduce() and functools.reduce() in 2.6. _

[issue2719] Backport next()

Raymond Hettinger <[EMAIL PROTECTED]> added the comment: ISTM, the only value added by next(g) is that it replaces g.next() with a more conventional spelling, g.__next__(). Since 2.6 still has g.next (),I don't see how this backport adds value. It does however create a second way to do it tha

[issue2719] Backport next()

New submission from Georg Brandl <[EMAIL PROTECTED]>: Backporting 3.0's next() builtin. There's no change w.r.t. __next__/next, that is tracked in #2336. -- assignee: gvanrossum components: Interpreter Core files: nextbackport.diff keywords: 26backport, patch messages: 65980 nosy: georg