[Python-Dev] Re: PEP 279 revisited (original) (raw)

Guido van Rossum guido@python.org
Wed, 24 Apr 2002 01:08:43 -0400

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/)