[issue2831] Adding start to enumerate()

Scott Dial added the comment: Created issue8636 for the broken test cases. -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue2831] Adding start to enumerate()

Nick Coghlan added the comment: Created issue 8635 for the incomplete docstring -- ___ Python tracker ___ ___ Python-bugs-list mailing

[issue2831] Adding start to enumerate()

George Sakkis added the comment: Just discovered this by chance; I would probably have noticed it earlier if the docstring had been updated. Let me know if it needs a new documentation bug ticket and I'll create one. Pretty handy feature by the way, thanks for adding it! -- nosy: +gs

[issue2831] Adding start to enumerate()

Georg Brandl <[EMAIL PROTECTED]> added the comment: Okay, committed a matching patch in r63208. Thank you all! -- resolution: -> accepted status: open -> closed __ Tracker <[EMAIL PROTECTED]> ___

[issue2831] Adding start to enumerate()

Guido van Rossum <[EMAIL PROTECTED]> added the comment: Sure, fine. __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: htt

[issue2831] Adding start to enumerate()

Georg Brandl <[EMAIL PROTECTED]> added the comment: Okay. I'm against making the argument keyword-only -- IMO keyword-only arguments really should only be used in cases where their existence has some advantage, like for max(). -- nosy: +georg.brandl __ Tr

[issue2831] Adding start to enumerate()

Guido van Rossum <[EMAIL PROTECTED]> added the comment: > Thanks. I think this part is the main reason I see a start argument to > enumerate as potentially problematic: > > """all variants can easily be misread as starting at the nth item in the > sequence (much like islice() does now): enume

[issue2831] Adding start to enumerate()

Nick Coghlan <[EMAIL PROTECTED]> added the comment: Mentioning the zip(count(start), itr) version in the enumerate() docs may be a good idea though. (And of course, in 2.x, it should be izip() rather than zip() to preserve the memory efficiency of enumerate()) __

[issue2831] Adding start to enumerate()

Nick Coghlan <[EMAIL PROTECTED]> added the comment: Note that this functionality is currently available as follows: >>> from itertools import count >>> list(zip(count(3), 'abcdefg') [(3, 'a'), (4, 'b'), (5, 'c'), (6, 'd'), (7, 'e'), (8, 'f'), (9, 'g')] The enumerate(itr) builtin is just a conve

[issue2831] Adding start to enumerate()

Raymond Hettinger <[EMAIL PROTECTED]> added the comment: FWIW, at one point, Guido rejected all variants of the idea. His first objection was that enumerate() is all about pairing values with sequence indices, so starting from anything other than zero is in conflict with the core concept. Hi

[issue2831] Adding start to enumerate()

Scott Dial <[EMAIL PROTECTED]> added the comment: As it stands, enumerate() already takes a "sequence" keyword as an alternative to the first positional argument (although this seems to be completely undocumented). So, as you say, METH_O is a no go. I agree with you in that my original complaint

[issue2831] Adding start to enumerate()

Raymond Hettinger <[EMAIL PROTECTED]> added the comment: Forget the part about METH_O. That was incorrect. Another idea to order the positional args as ([start,], iterator). That corresponds to with range([start,] stop) and it matches the output order (number, element): for i, element i

[issue2831] Adding start to enumerate()

Raymond Hettinger <[EMAIL PROTECTED]> added the comment: If a start argument gets accepted, it should be positional, not a keyword-only argument. That is a complete waste when there is just one argument with a straight-forward interpretation. Besides, METH_O is a lot faster than the alterna

[issue2831] Adding start to enumerate()

Changes by Scott Dial <[EMAIL PROTECTED]>: Added file: http://bugs.python.org/file10301/enumerate.diff __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs

[issue2831] Adding start to enumerate()

Changes by Scott Dial <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file10300/enumerate.diff __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bu

[issue2831] Adding start to enumerate()

Changes by Scott Dial <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file10299/enumerate.diff __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bu

[issue2831] Adding start to enumerate()

Changes by Scott Dial <[EMAIL PROTECTED]>: Added file: http://bugs.python.org/file10300/enumerate.diff __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs

[issue2831] Adding start to enumerate()

New submission from Scott Dial <[EMAIL PROTECTED]>: Georg Brandel suggested enumerate() should have the ability to start on an arbitrary number (instead of always starting at 0). I suggest such a parameter should be keyword-only. Attached is a patch to add such a feature along with added test cas