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

[Terry Reedy]

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 named<field>tuples 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