[Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as (original) (raw)

Terry Reedy tjreedy at udel.edu
Sat Feb 23 23:11:30 CET 2013

On 2/23/2013 12:46 PM, Nick Coghlan wrote:

For the standard library, we really don't care about any of those things, because we're currently using integers and strings for everything, so we can't add structure without risking breaking other people's code. However, just as we can get away with switching from producing and consuming tuples to producing and consuming namedtuples without breaking backwards compatibility, we could get away with producing and consuming names values in many cases, so long as those values behaved exactly like they did previously (i.e. as integers - there's little benefit to replacing our string "enums", since they're generally chosen for ease of debugging).

It seems that what would specifically be useful is a namedint class whose instances would be ints with a .name attribute and a custom .str and repr. (Note that None, False, and True do not have such because the name knowledge is elsewhere -- in str I would guess.) In all other respects, lets them be ints, just as namedtuples are otherwise tuples.

As you say, a namedstring is hardly useful as a string can be considered to be its own name.

I personally think we should skip the bikeshedding over how to avoid repeating names to make the bound name match the definition name (as with def, class, and import). Actually, they do not have to match and in cases, one might want a short bound name for retrieval and a longer definition name for display. In any case, compared to the number of functions, classes, and imported modules in the stdlib, there would only be a few namedints, and any typos would be caught very quickly.

In io (say)

stdin = namedint(1, 'stdin') # or namedint(1, 'standard input (fd 1)') etc plus 3 lines for seek.

-- Terry Jan Reedy

More information about the Python-Dev mailing list