See http://python.org/peps/pep-0279.html
There's one nagging issue that I'd like to revisit. I think I still like the name itemize() better than enumerate(), even though itemize() reminds some people of items(). Somehow that doesn't strike me as a strong argument: the words look pretty different to me. I like itemize() better because (a) it's shorter, and (b) the LaTeX command "\itemize" can produce numbered lists (it can also produce bulleted lists). I'm ready to open this one for a vote. :-)
--Guido van Rossum (home page: http://www.python.org/~guido/)
From: "Guido van Rossum" guido@python.org
There's one nagging issue that I'd like to revisit. I think I still like the name itemize() better than enumerate(),
<snip>
I'm ready to open this one for a vote. :-)
One other thought. As a design principle (from The Design of Everyday Things), knowledge of what something does and how to use it should be embedded in the object not in the user.
In this case, a person can learn to use either itemize() or enumerate() and bring that knowledge with them when they program. However, if the knowledge is not there (newbies), rusty (occasional users), or ambiguated (users of multiple languages), then the question arises of whether the name tells us what it does. For this reason, I vote for any name which suggests that numbers are going to come out.
An arbitrary enumerate() function is clearly going to create numbers while an itemize() found in the wild could potentially do something non-numeric. So while I could personally get used to either name and be happy, I think enumerate's two extra letters or one extra syllable is worth it.
'nuff said,
Raymond Hettinger
Raymond Hettinger python@rcn.com:
An arbitrary enumerate() function is clearly going to create numbers
But that's *not* clear to anyone who knows what the word "enumerate" really means, and isn't just guessing based on the fact that it has "num" in it.
There doesn't seem to be any single English word that captures all of what we mean without ambiguity. Maybe we should be making up a new word altogether, such as "numberize" or something.
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 +--------------------------------------+
On Wednesday 24 April 2002 07:02, Greg Ewing wrote: ...
There doesn't seem to be any single English word that captures all of what we mean without ambiguity.
Not a single VERB -- adjective "numbered" might do. Unfortunately the verb "to number" (from which the adjective comes as the past participle) is ambiguous when used as a function name (as noun "number" confusingly comes to mind instead, since it's an usage vastly more common).
Alex
--- Alex Martelli aleax@aleax.it wrote:
...
There doesn't seem to be any single English word that captures all of what we mean without ambiguity.
Not a single VERB -- adjective "numbered" might do. Unfortunately [...]
If there is no really good name, how about just adopting a new simple, short, word like "each", and letting it become the idiom?
for i, v in each(L): print i, v
It worked for "zip" right?
__________________________________________________ Do You Yahoo!? Yahoo! Games - play chess, backgammon, pool and more http://games.yahoo.com/
On Wednesday 24 April 2002 09:49 am, Scott Gilbert wrote: ...
There doesn't seem to be any single English word that captures all of what we mean without ambiguity.
Not a single VERB -- adjective "numbered" might do. Unfortunately [...]
If there is no really good name, how about just adopting a new simple, short, word like "each", and letting it become the idiom?
for i, v in each(L): print i, vIt worked for "zip" right?
I'd just love something like this, but unfortunately the precedent you cite probably does not apply: 'zip' is indeed a verb, 'each' is, alas, not.
What's now named 'enumerate', incidentally, is a type (just like 'tuple', 'dict', 'str' -- all consistently non-verbs, and types rather than functions since a few months), so I'm not quite sure why it should be a verb (what other types' names are verbs, except for the slight ambiguity of 'list' or 'file', which I've always perceived in the noun-sense anyway?).
Of course, if a noun was to be chosen instead, 'enumeration' and 'itemization' would be horrid (long and cumbersome), but maybe some other alternatives could be more appealing. 'items', for example, would be appealing to me personally (by the already mentioned "rough analogy" with a dictionary's .items method -- which turns others off by being only rough and not exact, so that D.items() and items(D) would be different sequences of pairs, albeit with similar structures, for just about any dict D).
Alex
On Wed, Apr 24, 2002 at 11:19:18AM +0200, Alex Martelli wrote:
Of course, if a noun was to be chosen instead, 'enumeration' and 'itemization' would be horrid (long and cumbersome), but maybe some other alternatives could be more appealing. 'items', for example, would be appealing to me personally (by the already mentioned "rough analogy" with a dictionary's .items method -- which turns others off by being only rough and not exact, so that D.items() and items(D) would be different sequences of pairs, albeit with similar structures, for just about any dict D).
I would like to transform the 'rough' analogy into an exact analogy :-)
If you consider lists to be a special dictionary with implicit keys we can define 'items' to generate (key,value) pairs for a collection so that
for key,value in items(collection): collection[key]==value
holds no matter if collection is a list or a dictionary,
Additionally
items(dict)==dict.items()
would be satisfied, so the analogy is better than 'rough'.
btw, i usually don't need an extra numbering for my dictionaries. If really in need i would write
list = dict.items() for index,item in items(list): ...
using the above semantics. Usually i use a list in the first place.
But i am afraid i am too late if this is the final voting...
holger
"hk" == holger krekel pyth@devel.trillke.net writes:
hk> P.S: As i am new to the list, i introduce myself here. hk> Mailman told me to :-)
Holger, I predict you'll work out great here. You're already following the first rule, which as the Timbot will tell you, is to always slavish do whatever Mailman tells you to do. It works for me, and not just because whenever I deviate from its plans, it smacks me on the head and forces me back into the party line.
-Barry
Barry A. Warsaw wrote
always slavish do whatever Mailman tells you to do. It works for me, and not just because whenever I deviate from its plans, it smacks me on the head and forces me back into the party line.
Great. So Barry does what Mailman tells him to do, and Barry modifies and improves Mailman. I predict a self-aware Mailman that kills us all within 2 years.
"AB" == Anthony Baxter anthony@interlink.com.au writes:
AB> Great. So Barry does what Mailman tells him to do, and Barry AB> modifies and improves Mailman. I predict a self-aware Mailman AB> that kills us all within 2 years.
You're thinking of the older Postman protocol (specifically GPP - the Go Postal Protocol), which was indeed prone to fits of violence. The newer MHHJJP (Mailman Happy Happy Joy Joy Protocol) wouldn't kill anybody or anything. It might turn you all into 'bots, but as the Tim and /F bots have shown, that may not be such a bad thing.
-B
holger krekel wrote:
[discussion on naming enumerate() items()]
Additionally
items(dict)==dict.items()
would be satisfied, so the analogy is better than 'rough'.
They are not equivalent, see below.
Neal --
d = {10:20} print d.items()
[(10, 20)]
print enumerate(d)
<enumerate object at 0x40208bcc>
for x in enumerate(d): print x
... (0, 10)
If you consider lists to be a special dictionary with implicit keys we can define 'items' to generate (key,value) pairs for a collection so that
for key,value in items(collection): collection[key]==valueholds no matter if collection is a list or a dictionary,
This has been proposed and rejected before. We've made the decision that "iter(dict)" iterates over the keys while "iter(list)" iterates over the values, and anything that tries to unify the two types (really categories of types: sequences and mappings) is bound to fail.
btw, i usually don't need an extra numbering for my dictionaries. If really in need i would write
list = dict.items() for index,item in items(list): ...using the above semantics.
That's another argument why what this function (whatever it's called) does on dicts is irrelevant: you wouldn't want to use it on a dict anyway. It's something for sequences and iterators.
--Guido van Rossum (home page: http://www.python.org/~guido/)
On Wed, Apr 24, 2002 at 08:47:25AM -0400, Guido van Rossum wrote:
If you consider lists to be a special dictionary with implicit keys we can define 'items' to generate (key,value) pairs for a collection so that
for key,value in items(collection): collection[key]==valueholds no matter if collection is a list or a dictionary,
This has been proposed and rejected before. We've made the decision that "iter(dict)" iterates over the keys while "iter(list)" iterates over the values, and anything that tries to unify the two types (really categories of types: sequences and mappings) is bound to fail.
ok, i am fine with that.
after all i can always define my own 'items' or maybe better 'keyvalues' method to achieve the unification where needed :-)
regarding PEP279 i go with 'itemize' ...
holger
On Wed, Apr 24, 2002 at 08:47:25AM -0400, Guido van Rossum wrote:
btw, i usually don't need an extra numbering for my dictionaries. If really in need i would write
list = dict.items() for index,item in items(list): ...using the above semantics.
That's another argument why what this function (whatever it's called) does on dicts is irrelevant: you wouldn't want to use it on a dict anyway. It's something for sequences and iterators.
Is it really a bad idea then to make 'this function' return something useful for mapping types?
This could also resolve the 'only rough analogy' problem for the name 'itemize' versus 'items'. (Although these two are really different words it is a little confusing even to demi-gods:-)
holger
Is it really a bad idea then to make 'this function' return something useful for mapping types?
Yes. Believe me. Don't go there.
(Sigh. I was only asking for guidance on whether to choose enumerate or itemize for the name, not reopening the whole subject of this PEP.)
--Guido van Rossum (home page: http://www.python.org/~guido/)
On Wed, 24 Apr 2002, Guido van Rossum wrote:
Is it really a bad idea then to make 'this function' return something useful for mapping types?
Yes. Believe me. Don't go there.
So should it explicitly raise a TypeError then, to avoid accidentally returning something (less than) useful ?
my +1 for calling it itemize, btw
/Paul
--- Guido van Rossum guido@python.org wrote:
(Sigh. I was only asking for guidance on whether to choose enumerate or itemize for the name, not reopening the whole subject of this PEP.)
/Smile. When I read the first message in this thread, I strongly suspected you threw this out there to verify the whole "the smaller the issue, the more people who will comment" theory that came up in the discussion of bools. I still strongly suspect that. :-)
__________________________________________________ Do You Yahoo!? Yahoo! Games - play chess, backgammon, pool and more http://games.yahoo.com/
[Alex Martelli]
What's now named 'enumerate', incidentally, is a type (just like 'tuple', 'dict', 'str' -- all consistently non-verbs, and types rather than functions since a few months), so I'm not quite sure why it should be a verb
I'm partial to enumerate, but agree with Alex that since it returns a type the name is less than satisfying. So I'd like to float the idea of using the Iterator spec as our model for this new type and function.
The new type is a numerator but that is a mouthful so the built-in function should be named numer(), just like iter() is short for iterator. If people can learn and remember iter(), it should be just as easy to learn and remember numer(). They are spelled almost the same, they rhyme, they are short, etc. All the logic that lead to the selection of iter() should apply here.
--- Patrick K. O'Brien Orbtech
On Wednesday 24 April 2002 05:34 pm, Patrick K. O'Brien wrote: ...
I'm partial to enumerate, but agree with Alex that since it returns a type
It IS a type; calling it returns an instance of the type. (Calling any callable returns an instance of SOME type, after all:-).
The new type is a numerator but that is a mouthful so the built-in function should be named numer(), just like iter() is short for iterator. If people
Nice. I doubt it will fly, but among the alternatives mentioned so far it gets my vote.
Alex
----- Original Message ----- From: "Alex Martelli" aleax@aleax.it
The new type is a numerator but that is a mouthful so the built-in
function
should be named numer(), just like iter() is short for iterator. If
people
Nice. I doubt it will fly, but among the alternatives mentioned so
far it
gets my vote.
Blick. Abbrevs suck. Plus I don't want to re-use the sucky name enum for something related to what 'C' and C++ use it for.
+1 for itemize +0.8 for enumerate (in other contexts/languages/systems it just returns the items in sequence like a python iterator does). OK, so round it up to 1 if fractions are illegal.
-Dave
On Wednesday 24 April 2002 18:13, David Abrahams wrote: ...
should be named numer(), just like iter() is short for iterator. If
...
Blick. Abbrevs suck. Plus I don't want to re-use the sucky name enum for something related to what 'C' and C++ use it for.
This proposal was for 'numer', not 'enum'. And, given a language that has a 'def' keyword, and built-ins called 'dict', 'iter', 'vars', 'bool', 'str', 'repr', etc (:-), the affermation "abbrevs suck" looks pretty peculiar to me. Note that a few of these are pretty new, too, so it's not a question of "legacy" -- clearly the designer _prefers_ to use abbreviations in certain places he deems suitable.
Alex
On Wed, Apr 24, 2002, Patrick K. O'Brien wrote:
The new type is a numerator but that is a mouthful so the built-in function should be named numer(), just like iter() is short for iterator. If people can learn and remember iter(), it should be just as easy to learn and remember numer(). They are spelled almost the same, they rhyme, they are short, etc. All the logic that lead to the selection of iter() should apply here.
Hrm. I'm not quite changing my vote yet, but numerator() might work; I don't like numer() because it looks like it's missing a "b". I'm also rethinking whether I should cast my vote for iterindexed().
If there is no really good name, how about just adopting a new simple, short, word like "each", and letting it become the idiom?
for i, v in each(L): print i, v
-1. each() doesn't convey any helpful connotations.
--Guido van Rossum (home page: http://www.python.org/~guido/)
On Wednesday 24 April 2002 03:37 pm, Neil Schemenauer wrote:
Greg Ewing wrote:
There doesn't seem to be any single English word that captures all of what we mean without ambiguity.
How about "indices"? You use a key to get things out of dictionaries. You use an index to get things out of sequences. "indices" is the pural of index.
Yes, but it's a noun, not a verb. Again, I don't understand why this type's name should be a verb, but apparently that's the Decision -- we're only being consulted on "which verb".
Apart from this, "indices" suggests you're getting ONLY indices -- while when you iterate on this type you get indices AND contents.
In other words, name "indices" might be fine for a hypothetical different type, for usage such as:
for i in indices(mysequence): x = mysequence[i] # etc
rather than the current:
for i in xrange(len(mysequence)): x = mysequence[i] # etc
but the type RH and I implemented (not without help from GvR in fixing the mess I'd made of GC &c:-) is to be used differently:
for i, x in mysterynamegoeshere(mysequence_or_other_iterator): # just the etc -- x, the i-th value, is already in hand
Alex
I'm glad I came across this post because I was about to write it myself. indices () seems like a good explanation of what's going on. It returns both the index and what it corresponds to. Much better than enumerate.
-- Mike
On Wed, Apr 24 @ 06:37, Neil Schemenauer wrote:
Greg Ewing wrote:
There doesn't seem to be any single English word that captures all of what we mean without ambiguity.
How about "indices"? You use a key to get things out of dictionaries. You use an index to get things out of sequences. "indices" is the pural of index.
Neil
Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev
`-> (nas)
One other thought. As a design principle (from The Design of Everyday Things), knowledge of what something does and how to use it should be embedded in the object not in the user.
I don't think this applies here -- all we've got is a *name*, not an inspectable object.
In this case, a person can learn to use either itemize() or enumerate() and bring that knowledge with them when they program. However, if the knowledge is not there (newbies), rusty (occasional users), or ambiguated (users of multiple languages), then the question arises of whether the name tells us what it does. For this reason, I vote for any name which suggests that numbers are going to come out.
Experimentation would also go a long way; even I often fire up an interactive interpreter to find out what a particular combination of operators or statements does.
An arbitrary enumerate() function is clearly going to create numbers while an itemize() found in the wild could potentially do something non-numeric. So while I could personally get used to either name and be happy, I think enumerate's two extra letters or one extra syllable is worth it.
I don't know about the assertion that enumerate() is clearly going to create numbers; the word is uncommon enough that most people might not have any preconceived notion of it (certainly not people whose first language is not English), and for people coming from C, C++ or Pascal it may have a strong association with enum types, which are not about numbers (in fact they are about abstraction away from numbers ;-).
Your "voter information" didn't mention this as a downside to enumerate(), but I think it's at least as important as the only argument against itemize (that it's not the same as items()). I just reviewed your implementation and noted that you abbreviated enumerate to enum everywhere, thereby closing the door for the "obvious" name (at the C API level) for an enum type, should we ever decide to add one.
--Guido van Rossum (home page: http://www.python.org/~guido/)
On Wednesday 24 April 2002 07:08, Guido van Rossum wrote: ...
I don't know about the assertion that enumerate() is clearly going to create numbers; the word is uncommon enough that most people might not have any preconceived notion of it (certainly not people whose first language is not English),
It has a Latin root ("numerus" == "number"), so people whose first language is a Romance one are well placed in this way. For example, "enumerare" is a common Italian verb (with roughly the same connotations as English "enumerate", but perhaps more easily felt connection with "numero").
and for people coming from C, C++ or Pascal it may have a strong association with enum types, which are not about numbers (in fact they are about abstraction away from numbers ;-).
Right -- "enumerate" as in "exhaustively list" something. When one does that in the real world one often attaches numbers to items too (perhaps silently, on one's fingers) as a help in ensuring exhaustivity, but Pascal most definitely doesn't (C/C++ don't hide the numbers so much).
Your "voter information" didn't mention this as a downside to enumerate(), but I think it's at least as important as the only argument against itemize (that it's not the same as items()). I just
I see the itemize/items issue as a _plus_ for itemize -- like items, it gives a sequence of pairs (x,v), and when the argument S is a sequence, v==S[x] -- reasonably similar (not "the same", sure, but if it WAS exactly "the same" we wouldn't have written it) to D.items() for a dict D returning a sequence [list rather than iterator] of pairs (x,v) such that v==D[x]. If the function's name didn't _have_ to be a verb (if it could follow the tradition of other builtin function names such as dir, vars, len, max and so on), naming the function "items" would emphasize this analogy.
My problem with "itemize" is that in LaTex and Texinfo it means a _bulleted_ (UN-numbered) list of items. In both cases, one uses "enumerate" instead, if one wants numbers rather than bullets. But it may well be that *Tex* are too obscure to worry about that.
reviewed your implementation and noted that you abbreviated enumerate to enum everywhere, thereby closing the door for the "obvious" name (at the C API level) for an enum type, should we ever decide to add
Sorry, my fault, not Raymond's -- I was working, as you had suggested, off the sources of iterobject.c (the 2.2.1 version, with old-fashioned GC, which doesn't excuse but may explain why I had left the GC in such a mess), and let the latter's widespread use of the abbreviations "iter_*" for "iterator" influence me into choosing "enum_*" analogously for "enumerate".
Alex
Alex Martelli wrote:
On Wednesday 24 April 2002 07:08, Guido van Rossum wrote: ...
I don't know about the assertion that enumerate() is clearly going to create numbers; the word is uncommon enough that most people might not have any preconceived notion of it (certainly not people whose first language is not English),
It has a Latin root ("numerus" == "number"), so people whose first language is a Romance one are well placed in this way.
Which is probably why I brought up this point originally. I'll be damned. My latin teacher was right. Latin and etymology classes _were_ going to be useful after all! =)
--davidatum ascherus
"Raymond Hettinger" python@rcn.com writes:
An arbitrary enumerate() function is clearly going to create numbers while an itemize() found in the wild could potentially do something non-numeric.
With the highschool English education I got, I would not associate "enumerate" with "numbers are coming out". Even if it was "aufzählen", I'd still not associate it with "Zahlen" in everyday's life.
Regards, Martin
[Martin v. Loewis]
With the highschool English education I got, I would not associate "enumerate" with "numbers are coming out". Even if it was "aufzählen", I'd still not associate it with "Zahlen" in everyday's life.
So +1 on zahlen() for this function's name <Wihnken>.
There's one nagging issue that I'd like to revisit. I think I still like the name itemize() better than enumerate(), even though itemize() reminds some people of items(). Somehow that doesn't strike me as a strong argument: the words look pretty different to me. I like itemize() better because (a) it's shorter, and (b) the LaTeX command "\itemize" can produce numbered lists (it can also produce bulleted lists). I'm ready to open this one for a vote. :-)
+1 on enumerate().
I must confess I didn't understand the idea just looking at that function's name. But once I've read the intention, I found the function name perfect for the job.
Btw, your second argument seems to strike against you. AFAIK, \begin{itemize} on LaTeX creates bulleted lists. To create enumerated lists you must use \begin{enumerate}. ;-)
Guido van Rossum guido@python.org:
See http://python.org/peps/pep-0279.html
There's one nagging issue that I'd like to revisit. I think I still like the name itemize() better than enumerate(), even though itemize() reminds some people of items(). Somehow that doesn't strike me as a strong argument: the words look pretty different to me. I like itemize() better because (a) it's shorter, and (b) the LaTeX command "\itemize" can produce numbered lists (it can also produce bulleted lists). I'm ready to open this one for a vote. :-)
Well, the itemize environment can create any kind of list, but you'll have to number the items manually... ;)
How about enum()? That's short, and sort of in the traditoin of iter()... Can either be interpreted as a noun, an adjective, or a verb...
--Guido van Rossum (home page: http://www.python.org/~guido/)
-- Magnus Lie Hetland The Anygui Project http://hetland.org http://anygui.org
Magnus Lie Hetland magnus@hetland.org: [snip]
How about enum()? That's short, and sort of in the traditoin of iter()... Can either be interpreted as a noun, an adjective, or a verb...
Oops... Should have read the list of existing suggestions more thoroughly. Sorry.
(Anyway... If possible, I vote for enum() -- otherwise, I vote for itemize(), exactly because of the "analogy" to dict.items)
-- Magnus Lie Hetland The Anygui Project http://hetland.org http://anygui.org
participants (20)
-
Aahz -
Alex Martelli -
Anthony Baxter -
barry＠zope.com -
David Abrahams -
David Ascher -
Greg Ewing -
Guido van Rossum -
Gustavo Niemeyer -
holger krekel -
Magnus Lie Hetland -
martin＠v.loewis.de -
Michael Gilfix -
Neal Norwitz -
Neil Schemenauer -
Patrick K. O'Brien -
Paul Svensson -
Raymond Hettinger -
Scott Gilbert -
Tim Peters