Theres one word that was left out from the discussion. numerate() As far as I can tell, the dictionary meaning is pretty much the same as for enumerate, but theres a much stronger association with numbering things (especially for non-latin speakers).
On Wednesday 24 April 2002 14:04, Damien Morton wrote:
Theres one word that was left out from the discussion.
numerate()
As far as I can tell, the dictionary meaning is pretty much the same as for enumerate, but theres a much stronger association with numbering things (especially for non-latin speakers).
I think the main use of 'numerate' is as an adjective meaning roughly the same as 'literate' but about numbers/maths rather than about 'letters' (words/writing/reading/...). Didn't know it was a verb in English (in Italian the equivalent "numerare" exists, and means "associate numbers with" more strictly than "enumerare" does, so it _would_ be perfect for a native speaker of Italian -- hardly an important issue, though). Alex
http://www.dictionary.com/search?q=numerate ------------------------ tr.v. nu.mer.at.ed, nu.mer.at.ing, nu.mer.ates To enumerate; count. adj. (-mr-t) Able to think and express oneself effectively in quantitative terms. Source: The American HeritageR Dictionary of the English Language, Fourth Edition ------------------------- \Nu"mer*ate\, v. t. [imp. & p. p. Numerated; p. pr. & vb. n. Numerating.] [L. numeratus, p. p. of numerare to count. See Number, v.] (Arith.) To divide off and read according to the rules of numeration; as, to numerate a row of figures. Source: Webster's Revised Unabridged Dictionary, C 1996, 1998 MICRA, Inc. ------------- Of course, the fundamental operation here is numbering things in a list. list.number() perhaps? Unfortunatly, the noun/verb ambiguity exists with that suggestion, but... I like numerare, it would be a fine suggestion if more of the world spoke Italian.
-----Original Message----- From: Alex Martelli [mailto:aleax@aleax.it] Sent: Wednesday, 24 April 2002 08:11 To: Damien Morton; python-dev@python.org Subject: Re: [Python-Dev] re: PEP 279 revisited
Theres one word that was left out from the discussion.
numerate()
As far as I can tell, the dictionary meaning is pretty much
On Wednesday 24 April 2002 14:04, Damien Morton wrote: the same
as for enumerate, but theres a much stronger association with numbering things (especially for non-latin speakers).
I think the main use of 'numerate' is as an adjective meaning roughly the same as 'literate' but about numbers/maths rather than about 'letters' (words/writing/reading/...). Didn't know it was a verb in English (in Italian the equivalent "numerare" exists, and means "associate numbers with" more strictly than "enumerare" does, so it _would_ be perfect for a native speaker of Italian -- hardly an important issue, though).
Alex
Theres one word that was left out from the discussion.
numerate()
As far as I can tell, the dictionary meaning is pretty much the same as for enumerate, but theres a much stronger association with numbering things (especially for non-latin speakers).
I'm +/- 0 on this. It saves a letter and may indeed suggest numbering more closely, but it's an even more obscure word than enumerate(). BTW, the two votes I've received so far were in favor of enumerate(). --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
...
I'm +/- 0 on this. It saves a letter and may indeed suggest numbering more closely, but it's an even more obscure word than enumerate().
Is not obscurity a sort of virtue? If it hasn't been used in the languages space then it has no mental baggage. Compare with "Big endian", as obscure a reference as you'll find in computer science, I think. Or "thunk": a made-up word. Paul Prescod
Paul Prescod wrote:
Guido van Rossum wrote:
...
I'm +/- 0 on this. It saves a letter and may indeed suggest numbering more closely, but it's an even more obscure word than enumerate().
Is not obscurity a sort of virtue? If it hasn't been used in the languages space then it has no mental baggage. Compare with "Big endian", as obscure a reference as you'll find in computer science, I think. Or "thunk": a made-up word.
Let's try and approach this from a formal POV. For a representative population of target users, if they see code using name X, what is the likelihood of (a) - guessing the meaning correctly ; (b) - guessing the meaning incorrectly; (c) - refusing to guess and looking it up. Now design a cost function C(a,b,c|X), and minimize over X. The details are in the cost function particulars: Paul's cost function says that what matters is minimizing b, even if it means increasing c. A made-up word or one with no 'likely to guess' meaning, is safest as far as that cost function is concerned. Admittedly, it doesn't take into account the cost of looking things up. Another cost function would be to maximize (a-b), ignoring c. That is what people seem to be 'voting' on, I think, although more analysis would be needed to make that a strong claim. There seem to be anecdotal data flying (again =) indicating that if either enumerate or itemize are chosen for X, a and b are likely to be similar in magnitude and would dwarf c. Given that, the two cost functions yield very different data. What cost function do we want to apply to such things? Do we have previous experiences with bad names that had bad consequences? My personal "naming" problems in Python has to do with never remembering the order of the two arguments to pickle.dump(). I get it wrong about 50% of the time if I haven't been pickling recently. Along the same lines, I have no problem remembering the name of the pickle module, even though its relationship to the semantics are fairly abstract at best. I'm reluctant to vote between enumerate and itemize because I think Paul's onto something. I'll close with an anecdote which is even harder to apply to the case at hand. My mom recently got her first Windows PC after using macs for years. I'm talking to her on the phone: "How do I throw things off of my desktop?" "Just drag them to the trash can" "But there's no trash can ... . oh, there's a recycle bin -- but I do't want to recycle, I want to throw it away!" --da
David Ascher wrote:
... Let's try and approach this from a formal POV.
My only addition to your formal model is a factor for mnemonic-ness. I like "numerate" because I wouldn't have a bunch of preconditions but once I figured out what it meant I'd remember it. Paul Prescod
David Ascher wrote:
I'll close with an anecdote which is even harder to apply to the case at hand. My mom recently got her first Windows PC after using macs for years. I'm talking to her on the phone:
"How do I throw things off of my desktop?" "Just drag them to the trash can" "But there's no trash can ... . oh, there's a recycle bin -- but I do't want to recycle, I want to throw it away!"
Given that Mac users eject removable media by dragging the media's icon onto the trashcan, presumably there is already some ambiguity in their minds about what the trashcan does. An interesting conversation often results from asking Americans what the difference is between trash and garbage. Given that the answer is "garbage contains food waste", perhaps we should really trash-collect objects when their refcount becomes zero? I now return you to this important semantic discussion <0.85 wink>. unless-of-course-you-eat-objects-ly y'rs - steve -- home: http://www.holdenweb.com/ Python Web Programming: http://pydish.holdenweb.com/pwp/
Thanks to all for the feedback. I think I've seen slightly more votes for enumerate than for itemize, and after some thought I think the LaTeX example (where enumerate creates numbered items) *does* help -- even if few Python users know LaTeX, I trust the linguistic sensibilities of LaTeX' author. So enumerate() it is. (Specifically not enum() because of the C/C++ meaning of that word.) --Guido van Rossum (home page: http://www.python.org/~guido/)
[Guido]
... So enumerate() it is. (Specifically not enum() because of the C/C++ meaning of that word.)
The C/C++ meaning isn't a barrier to me: a C enum decl without embedded '=' must associate 0 with the first name, 1 with the second name, and so on. Indeed, if the Python enum returned pairs in (value, index) order, dict(enum(['apple', 'pear', 'godzilla']) would create the dict {'apple': 0, 'pear': 1, 'godzilla': 2} which is about as close to the C enum {apple, pear, godzilla}; /* now apple==0, pear==1, godzilla==2 */ as you can get with a Python function.
----- Original Message ----- From: "Tim Peters" <tim.one@comcast.net> To: <python-dev@python.org> Sent: Friday, April 26, 2002 11:58 AM Subject: RE: [Python-Dev] re: PEP 279 revisited, formally
[Guido]
... So enumerate() it is. (Specifically not enum() because of the C/C++ meaning of that word.)
The C/C++ meaning isn't a barrier to me: a C enum decl without embedded '=' must associate 0 with the first name, 1 with the second name, and so on. Indeed, if the Python enum returned pairs in (value, index) order,
dict(enum(['apple', 'pear', 'godzilla'])
would create the dict
{'apple': 0, 'pear': 1, 'godzilla': 2}
which is about as close to the C
enum {apple, pear, godzilla}; /* now apple==0, pear==1, godzilla==2 */
as you can get with a Python function.
+1 -- home: http://www.holdenweb.com/ Python Web Programming: http://pydish.holdenweb.com/pwp/
Tim Peters <tim.one@comcast.net>:
[Guido]
... So enumerate() it is. (Specifically not enum() because of the C/C++ meaning of that word.)
The C/C++ meaning isn't a barrier to me: a C enum decl without embedded '=' must associate 0 with the first name, 1 with the second name, and so on. Indeed, if the Python enum returned pairs in (value, index) order,
dict(enum(['apple', 'pear', 'godzilla'])
would create the dict
{'apple': 0, 'pear': 1, 'godzilla': 2}
which is about as close to the C
enum {apple, pear, godzilla}; /* now apple==0, pear==1, godzilla==2 */
as you can get with a Python function.
+1 -- Magnus Lie Hetland The Anygui Project http://hetland.org http://anygui.org
participants (9)
-
Alex Martelli -
Damien Morton -
David Ascher -
Fredrik Lundh -
Guido van Rossum -
Magnus Lie Hetland -
Paul Prescod -
Steve Holden -
Tim Peters