[Python-Dev] Re: PEP 279 revisited

[Guido van Rossum]

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