Re: [Python-Dev] Re: PEP 279
After some more thinking about the name, I have two contenders left: enumerate() and indexer(). Let me explain why I reject the others:
iterindexed()-- five syllables is a mouthfull
Indeed.
index() -- nice verb but could be confused the .index() method
Indeed.
indexed() -- widely liked however adjectives should be avoided
Indeed.
count() -- direct and explicit but often used in other contexts
In particular, there's a list method by this name. While that's in a different namespace, I think the core language should be careful not to pile too many meanings on the same name.
itercount() -- direct, explicit and hated by more than one person
Did they explain why they hated it? "Hate it" alone doesn't get much credit in my book.
iteritems() -- already used by dictionaries for key:value pairs
Which is a downside to me. The symmetry between (key:value) for mappings and (index:value) for sequences seems appealing but quickly becomes a problem, e.g. "for i in <list>" iterates over the values but "for i in <dict>" iterates over the keys. So now I'd like to choose between enumerate() and indexer(). Any closing arguments? --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum writes:
So now I'd like to choose between enumerate() and indexer(). Any closing arguments?
"indexer" is the name of the built-in full-text indexer, right? ;-) -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation
"GvR" == Guido van Rossum
writes:
GvR> So now I'd like to choose between enumerate() and indexer(). GvR> Any closing arguments? Let me enumerate the reasons while I like the one I do: 1. it clearly describes the action being performed 2. see #1 3. it is a verb, which (to me) seems more preferable than a noun 4. there is /no/ ... number 4 5. indexer() seems too tied to search engines 6. Need I say more? :) -Barry
So now I'd like to choose between enumerate() and indexer(). Any closing arguments?
I'm leaving that quote anonymous so nobody gives it more or less weight than it deserves <wink>. I prefer enumerate(), because a transitive verb is more appropriate than a noun. OTOH, enumerate() is just a fancy pants way of saying "countoff()", which is nicely confusable with operator.countOf if you're tired <wink>.
Guido van Rossum wrote:
So now I'd like to choose between enumerate() and indexer(). Any closing arguments?
A few thoughts: + the nice thing about enumerate is that it has the word 'number' in it. - it is not obvious to me at first blush that 'enumerating' and 'iterating' elicit different 'first-guess semantics' - The first meaning I'd guess for enumerate(foo) would be range(len(foo)). One reason I suggested 'indexer' is that the tuples (index, element) are what I think of as an index entry -- it's a pair of (key, the element being located) A problem with indexer that I just realized is that indexer(dictionary) does return (number, value) pairs, while one might reasonably expect it to generate the same thing as dictionary.iteritems(). >>> print d {'y': 'foo', 'x': 123, 'z': 1j} >>> for (k,v) in indexer(d): ... print k, v ... 0 y 1 x 2 z >>> for (k,v) in d.iteritems(): ... print k, v ... y foo x 123 z 1j >>> for (k,v) in enumerate(d): ... print k, v ... 0 y 1 x 2 z Actually, having the function return the dictionary _keys_ as the second element in the tuple is a little weird. But I guess that's just the consequence of the earlier choice w.r.t. iter(dict). All things considered, even though I suggested 'indexer()', I'm voting for 'enumerate()' because of the numeric focus as opposed to a 'key' focus. --da
So now I'd like to choose between enumerate() and indexer(). Any closing arguments?
I'm leaving that quote anonymous so nobody gives it more or less weight
From: "Tim Peters"
it deserves <wink>. I prefer enumerate(), because a transitive verb is more appropriate than a noun. OTOH, enumerate() is just a fancy pants way of saying "countoff()", which is nicely confusable with operator.countOf if you're tired <wink>.
I agree. Enumerate is a direct, unequivocable verb that speaks directly to the idea of sequentially assigning numbers to things. Countoff is cool, but is a little colloquial. Also, any of the words incorporating count (including itercount and countoff) have a subtle implicit suggestion of counting from one rather than zero -- "firstly, let's take item zero ..." While indices have a clear meaning in Python, the old Dbase and SQL part of me is a little bugged by index(), indexed(), indexer() since sequential files are not at all like indexed files. When I index a database, sorting takes place. When I index a collection, sequencing is applied. Much different. As a part of speech, indexer() doesn't work as well in a sentence: for linenum, line in indexer(file): ... # yuck! Summary, I think we're down to subtle differences and have the following preference order: 1. enumerate 2. countoff 3. indexed 4. itercount OTOH, no one has ever accused me of having good taste <wink> Raymond Hettinger
[Raymond Hettinger]
... Summary, I think we're down to subtle differences and have the following preference order: 1. enumerate 2. countoff 3. indexed 4. itercount
No, no, no. That's not the Python Way. These aren't subtle differences, "enumerate" is the correct choice and all the others are plain *stupid*. TOOWTDI! Once you embrace the blinding obviousness of that, you'll have no trouble at all understanding why extending generators meets with so much otherwise inexplicable resistance <wink>.
OTOH, no one has ever accused me of having good taste <wink>
You're in danger of them starting to, provided Guido picks enumerate. Then people will remember that you channeled him successfully. But if he doesn't pick enumerate, all they'll remember is that you ran around half insane, accusing everyone who didn't vote for the loser "enumerate" of trying to destroy Python. This is a very delicate time in your Python Career. doubting-anyone-will-get-much-sleep-tonight-ly y'rs - tim
From: "Tim Peters"
No, no, no. That's not the Python Way. These aren't subtle differences, "enumerate" is the correct choice and all the others are plain *stupid*. TOOWTDI! Once you embrace the blinding obviousness of that, you'll have
no
trouble at all understanding why extending generators meets with so much otherwise inexplicable resistance <wink>.
Of course, how could I have been so blind.
OTOH, no one has ever accused me of having good taste <wink>
You're in danger of them starting to, provided Guido picks enumerate.
Then
people will remember that you channeled him successfully. But if he doesn't pick enumerate, all they'll remember is that you ran around half insane, accusing everyone who didn't vote for the loser "enumerate" of trying to destroy Python. This is a very delicate time in your Python Career.
The scales are starting to tip. But which way? <shivers>
doubting-anyone-will-get-much-sleep-tonight-ly y'rs - tim
Now, that's a great idea. See you guys tomorrow. It's time for me to enumerate(sheep). Raymond
On Tue, 2 Apr 2002, Raymond Hettinger wrote:
Now, that's a great idea. See you guys tomorrow. It's time for me to enumerate(sheep).
I prefer "enumerate" to "indexer" as well, though it's a bit long. "enum" would be nice. (I don't really see how it would ever collide with C's meaning for "enum" -- the current idiom for simulating enumerated types is very different, and even if Python eventually gets a type system fancy enough to handle types with alternatives, we won't use "enum" to describe them -- we'll just have alternatives, and probably use "|" or something like that.) -- ?!ng
Summary, I think we're down to subtle differences and have the following preference order: 1. enumerate
Forget the others you mentioned, but insert one at the top, so we get: 0. itemize 1. enumerate --Guido van Rossum (home page: http://www.python.org/~guido/)
Forget the others you mentioned, but insert one at the top, so we get:
0. itemize 1. enumerate
Itemize() is too close to the unrelated concept of items:
d = { 'red':'roja', 'blue':'azul' } d.items() [('blue', 'azul'), ('red', 'roja')] list(itemize(d)) [(0,'blue'), (1,'red')]
Let's stick with enumerate(). Raymond
On Tue, 2 Apr 2002, Tim Peters wrote:
So now I'd like to choose between enumerate() and indexer(). Any closing arguments?
I'm leaving that quote anonymous so nobody gives it more or less weight than it deserves <wink>. I prefer enumerate(), because a transitive verb is more appropriate than a noun. OTOH, enumerate() is just a fancy pants way of saying "countoff()", which is nicely confusable with operator.countOf if you're tired <wink>.
I know i'm late for this party, but i'd like to introduce 'itemize()'. "Everybody, itemize(). Itemize(), everybody. Pleased to meetcha, i'm sure." Nice thing about itemize is it turns values into key/value tuples, much like .items() on various sequences. -- Ken klm@zope.com
On Tue, 2 Apr 2002, Ken Manheimer wrote:
On Tue, 2 Apr 2002, Tim Peters wrote:
So now I'd like to choose between enumerate() and indexer(). Any closing arguments?
I'm leaving that quote anonymous so nobody gives it more or less weight than it deserves <wink>. I prefer enumerate(), because a transitive verb is more appropriate than a noun. OTOH, enumerate() is just a fancy pants way of saying "countoff()", which is nicely confusable with operator.countOf if you're tired <wink>.
I know i'm late for this party, but i'd like to introduce 'itemize()'.
"Everybody, itemize(). Itemize(), everybody. Pleased to meetcha, i'm sure."
Nice thing about itemize is it turns values into key/value tuples, much like .items() on various sequences.
Whoops, twice - ".items() on mappings", and i was wrong, besides, as raymond pointed out... -- Ken klm@zope.com
Guido:
0. itemize 1. enumerate
I'd like to add: 2. number It says pretty much what we mean -- number these items, i.e. assign a number to each one. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+
Guido:
0. itemize 1. enumerate
[Greg E]
I'd like to add:
2. number
-1. It looks like a noun to me. --Guido van Rossum (home page: http://www.python.org/~guido/)
----- Original Message -----
From: "Guido van Rossum"
0. itemize 1. enumerate
After the conversation on names, are you ready to choose between enumerate(), enum(), and itemize()? enumerate -- I like this one best because it does what it says. Liked by most of the py-dev respondants. enum -- I like this one too. A tiny bit of clarity traded for pithiness (like dict vs dictionary). Must rhyme with 'doom', not with 'dumb' <grin>. itemize -- Could be confusing since amap.items() != list(itemize(amap)). Unfortunate association with income taxes :( Raymond Hettinger, CPA
0. itemize 1. enumerate
After the conversation on names, are you ready to choose between enumerate(), enum(), and itemize()?
enumerate -- I like this one best because it does what it says. Liked by most of the py-dev respondants.
This one gets my vote.
enum -- I like this one too. A tiny bit of clarity traded for pithiness (like dict vs dictionary). Must rhyme with 'doom', not with 'dumb' <grin>.
Too similar to enum in tons of other languages.
itemize -- Could be confusing since amap.items() != list(itemize(amap)). Unfortunate association with income taxes :(
I hear this over and over so I give up on it. IOW, enumerate() it is. When you send Barry your update to the PEP reflecting this, he can mark it Accepted. (I still find it strange to mark a PEP Accepted that has two parts, only one of which is accepted. But so be it. Next time be sure to make separate PEPs.) --Guido van Rossum (home page: http://www.python.org/~guido/)
"GvR" == Guido van Rossum
writes:
GvR> (I still find it strange to mark a PEP Accepted that has two GvR> parts, only one of which is accepted. But so be it. Next GvR> time be sure to make separate PEPs.) I've added some language to PEP 1 to more strongly encourage focussed, smaller PEPs. I'll reserve the right in the future to reject PEPs that seem too broad. -Barry
Raymond Hettinger
enumerate -- I like this one best because it does what it says.
But it doesn't. According to the Merriam-Webster dictionary, enumerate means either "to ascertain the number of : COUNT" or "to specify one after another : LIST". The first is what len() does, and the second doesn't require doing anything. Neither of these is what we want. I notice that "numerate" is listed in the thesaurus as a synonym for "enumerate". Maybe it could serve as a compromise between "enumerate" and "number"? Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+
[Greg Ewing]
Raymond Hettinger
: enumerate -- I like this one best because it does what it says.
But it doesn't. According to the Merriam-Webster dictionary, enumerate means either "to ascertain the number of : COUNT" or "to specify one after another : LIST".
Maybe a more generous dictionary would help. <0.5 wink> http://www.dictionary.com/search?q=enumerate Included in the Webster's Revised Unabridged Dictionary are phrases such as: "to tell by numbers; to count over, or tell off one after another; to mention one by one; to name over; to make a special and separate account of" Sounds close enough to me. Extremely close, actually. And I don't think we'll find anything better. --- Patrick K. O'Brien Orbtech
----- Original Message -----
From: "Patrick K. O'Brien"
Maybe a more generous dictionary would help. <0.5 wink>
http://www.dictionary.com/search?q=enumerate
Included in the Webster's Revised Unabridged Dictionary are phrases such as:
"to tell by numbers; to count over, or tell off one after another; to mention one by one; to name over; to make a special and separate account of"
Sounds close enough to me. Extremely close, actually.
I agree.
And I don't think we'll find anything better.
Enumerat's OK with me, but I want to put in another plug for itemize(), which is in the thesaurus as a synonym. Think of what an itemized list is, for example: 1. foo 2. bar 3. baz 4. ... -Dave
participants (12)
-
barry@zope.com
-
David Abrahams
-
David Ascher
-
Fred L. Drake, Jr.
-
Greg Ewing
-
Guido van Rossum
-
Ka-Ping Yee
-
Ken Manheimer
-
Neil Schemenauer
-
Patrick K. O'Brien
-
Raymond Hettinger
-
Tim Peters