Subject: Re: [Python-Dev] Re: PEP 279 From: Guido van Rossum <guido@python.org> Date: Fri, 29 Mar 2002 01:41:05 -0500
[GvR] > I like the idea of having some way to iterate over a sequence and [GvR] > its index set in parallel. It's fine for this to be a builtin.
[RDH] Great! [RDH] > I like itercount() or enumerate(). The reason is that this [RDH] > function can work with any iterable including those that [RDH] > do not have numeric indices (such as dictionaries). [RDH] > Counting or enumeration is what is really happening.
[GvR] I don't like either of those, you don't seem to like iterindexed(), so [GvR] we'll have to think more about a name. [Just] I quite like the name enumerate. Hate itercount. I'm neutral on indexed. [RDH] > 3. itercount(collection) # good enough [GvR] I really hate the alternate count option, so let's agree to pick 3 [GvR] (with a different name). Done! Though my tastes are a little different, iterindexed() works just fine. I'm agreed (agreeing with dictators is good for ones health :-) to option three as you wrote it: [GvR] def iterindexed(collection): [GvR] i = 0 [GvR] it = iter(collection) [GvR] while 1: [GvR] yield (i, it.next()) [GvR] i += 1 Thank you. I'll put it back it the PEP just like this and mark it as Accepted.
2. Generator comprehensions
[GvR] If the only way to get you to stop asking for this is a -1 from me, [GvR] I'll give it a -1. Okay, I'll mark this one as rejected. The rationale for the rejection will be that the implementation and maintenance complexities exceed the added value. The added value would be minimal because it's already easy to code the generator directly. [RDH] > Several commenters wanted this one quite a bit. An excerpt: "This [RDH] > rules. You rock." [GvR] Yeah, if I left Python's design to Ping, it would become quite the [GvR] clever hack. :-) Poor Ping, getting a little public ribbing for foolishly supporting my proposal <grin> when the comment actually came from Kragen Sitaker :)
3. Generator exception passing
[RDH] > I need help from others on py-dev who can articulate the need clearly. [RDH] > For me, it's as plain as day and I don't know what to say to convey the [RDH] > message better than it is expressed in the PEP.
[GvR] Too bad. This one gets a big fat -1 until there's a good motivational [GvR] section. Okay, let's defer this one until the case for or against becomes stronger. I'll move it to join the separate PEP for generator parameter passing. Putting that one in a separate pep was necessary because it wasn't yet ready for pronoucement. I'll mark the two (exception passing and parameter passing) as being proposed for 2.4 or later and note that the case is not currently strong enough to warrant acceptance. Executive Summary: 1. iterindexed(collection) --> accepted 2. gen comprehensions --> rejected 3. gen exception passing --> deferred, needs case building 4. gen parameter passing --> deferred, needs alternatives explored Everyone, thank you for your time and thoughtful comments. We're done. Raymond Hettinger _ ~ @ @ \_/
Executive Summary: 1. iterindexed(collection) --> accepted
Except I want to think more about the name.
2. gen comprehensions --> rejected
Good.
3. gen exception passing --> deferred, needs case building
OK (or you could give up now while you're ahead :-).
4. gen parameter passing --> deferred, needs alternatives explored
That one was already taken out of the PEP. I think that #3 probably fits better in the new PEP you were gonna write for #4. But to be honest, I don't encourage you to write it -- I expect I'm gonna reject both in the end. But I can't stop you. :-) --Guido van Rossum (home page: http://www.python.org/~guido/)
3. gen exception passing --> deferred, needs case building
OK (or you could give up now while you're ahead :-).
4. gen parameter passing --> deferred, needs alternatives explored
That one was already taken out of the PEP. I think that #3 probably fits better in the new PEP you were gonna write for #4. But to be honest, I don't encourage you to write it -- I expect I'm gonna reject both in the end. But I can't stop you. :-)
That's cool. Better to be fully thought out, documented, and rejected than to be half-baked and in limbo for perpetuity. Besides, you might even like the revised proposal. I think I've found a very clean, consistent, pythonic way to avoid the problem with the thrown away call to next(). rejection-is-a-form-of-progress-ly yours, Raymond Hettinger
[RDH]
Executive Summary: 1. iterindexed(collection) --> accepted [GvR] Except I want to think more about the name.
Okay, here's what we have so far: iterindexed()-- five syllables is a mouthfull index() -- nice verb but could be confused the .index() method indexed() -- widely liked however adjectives should be avoided count() -- direct and explicit but often used in other contexts itercount() -- direct, explicit and hated by more than one person enumerate() -- a contender but doesn't mention iteration or indices iteritems() -- already used by dictionaries for key:value pairs Raymond Hettinger, CPA ------------------------------------------------------------------- def iterindexed(collection): 'Generates an indexed series: (0,coll[0]), (1,coll[1]) ...' i = 0 it = iter(collection) while 1: yield (i, it.next()) i += 1
Guido van Rossum wrote:
Executive Summary: 1. iterindexed(collection) --> accepted
Except I want to think more about the name.
Please do! I like it about as much as I like dict.setdefault. Not. Now, if you called it "orlijn", that'd be nice. =) --da
[Raymond Hettinger]
Okay, here's what we have so far:
iterindexed()-- five syllables is a mouthfull index() -- nice verb but could be confused the .index() method indexed() -- widely liked however adjectives should be avoided count() -- direct and explicit but often used in other contexts itercount() -- direct, explicit and hated by more than one person enumerate() -- a contender but doesn't mention iteration or indices iteritems() -- already used by dictionaries for key:value pairs
Since Guido is sticking to bool() for his current PEP, I guess that leaves truth() open for this <wink>. iotazip() is a natural for those with both APL and Haskell backgrounds, and sounds way cool if you're burned out. ordinalize() is an even clumsier way to say enumerate(). poll() would confuse everyone almost equally. countoff() brings to mind a common isomorphic procedure in American schools ("One!", "Two!", "Three!", ...). I kinda like it, although zerobasedcountoff() may be more appropriate here <wink>. rollcall() is cute. paginate() is descriptive for one specific application. If indexed() is disliked just because it's an adjective, Google finds only one hit for indicify(). indexify() gets 103. I'm amazed that Marc-Andre's irange() isn't already in the list (it's part of his mxTools Python extension).
[Raymond Hettinger]
enumerate() -- a contender but doesn't mention iteration or indices
I certainly like this name the best of the options I've heard so far. It seems clear enough to me, at any rate. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation
My current fave is 'indexer'. Something which creates an index. --da
[RDH]
Executive Summary: 1. iterindexed(collection) --> accepted [GvR] Except I want to think more about the name.
Okay, here's what we have so far:
iterindexed()-- five syllables is a mouthfull index() -- nice verb but could be confused the .index() method indexed() -- widely liked however adjectives should be avoided count() -- direct and explicit but often used in other contexts itercount() -- direct, explicit and hated by more than one person enumerate() -- a contender but doesn't mention iteration or indices iteritems() -- already used by dictionaries for key:value pairs
[David Ascher]
My current fave is 'indexer'. Something which creates an index.
I like it! Raymond, what do you think? --Guido van Rossum (home page: http://www.python.org/~guido/)
Tim Peters wrote:
[Raymond Hettinger]
Okay, here's what we have so far:
iterindexed()-- five syllables is a mouthfull index() -- nice verb but could be confused the .index() method indexed() -- widely liked however adjectives should be avoided count() -- direct and explicit but often used in other contexts itercount() -- direct, explicit and hated by more than one person enumerate() -- a contender but doesn't mention iteration or indices iteritems() -- already used by dictionaries for key:value pairs
Since Guido is sticking to bool() for his current PEP, I guess that leaves truth() open for this <wink>.
iotazip() is a natural for those with both APL and Haskell backgrounds, and sounds way cool if you're burned out.
ordinalize() is an even clumsier way to say enumerate().
poll() would confuse everyone almost equally.
countoff() brings to mind a common isomorphic procedure in American schools ("One!", "Two!", "Three!", ...). I kinda like it, although zerobasedcountoff() may be more appropriate here <wink>.
rollcall() is cute.
paginate() is descriptive for one specific application.
If indexed() is disliked just because it's an adjective, Google finds only one hit for indicify(). indexify() gets 103.
I'm amazed that Marc-Andre's irange() isn't already in the list (it's part of his mxTools Python extension).
As long as you remain backwards compatible with irange() I don't have objections ;-) (same for the other extra builtins in mxTools) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
participants (6)
-
David Ascher -
Fred L. Drake, Jr. -
Guido van Rossum -
M.-A. Lemburg -
Raymond Hettinger -
Tim Peters