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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
