This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author gvanrossum
Recipients gvanrossum, ncoghlan, rhettinger, scott.dial
Date 2008-05-13.14:24:49
SpamBayes Score 0.0010391565
Marked as misclassified No
Message-id <1210688796.92.0.949122606626.issue2831@psf.upfronthosting.co.za>
In-reply-to
Content
> 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):   enumerate(3, 'abcdefg') -->
>   (3,'d') (4,'e') (5, 'f') (6, 'g')."""

So the ambiguity is that enumerate(it, start=N) could be taken as
skipping the first N items of it rather than adding N to the index it
returns. (And it is my own argument!) I'd like to withdraw this
argument. There are two separate use cases for using enumerate(): one is
to iterate over a sequence and to have a handy index by which to update
the value in the sequence. Another is for 1-based counting, usually when
printing 1-based ordinals (such as line numbers in files, dates in a
month or months in a year, etc.). N-based counting is less common but
still conceivable. However I see no use for skipping items from the
start, and if that use case ever came up, passing a slice to enumerate()
would be the appropriate thing to do. In fact, if you passed in a slice,
you might also want to pass a corresponding start value so the indices
produced match those of the original sequence.

So, I am still in favor of adding a new argument to enumerate().

I'm neutral on the need for a keyword (don't think it would hurt, not
sure how much it matters). I'm strongly against making it an optional
*leading* argument like Raymond proposed; that's a style I just don't
want to promote, range() and the curses module notwithstanding.

> Is the need to use zip(count(3), seq) for the offset index case really
such
> a burden given the associated benefits in keeping the builtin function
> really simple and easy to understand?

Yes, zip(count(3), seq) is too complex for this simple use case. I've
always solved this so far with this less-than-elegant but certainly
simpler idiom (except for users stuck in the tradition of for-loops in
certain older languages :-):

for i, line in enumerat(lines):
  i += 1
  print "%4d. %s" % (i, line)

and variants thereof.
History
Date User Action Args
2008-05-13 14:26:44gvanrossumsetspambayes_score: 0.00103916 -> 0.0010391565
recipients: + gvanrossum, rhettinger, ncoghlan, scott.dial
2008-05-13 14:26:38gvanrossumsetspambayes_score: 0.00103916 -> 0.00103916
messageid: <1210688796.92.0.949122606626.issue2831@psf.upfronthosting.co.za>
2008-05-13 14:26:33gvanrossumlinkissue2831 messages
2008-05-13 14:25:45gvanrossumcreate