[Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as
ncoghlan at gmail.com
Sun Feb 24 03:19:41 CET 2013
On 24 Feb 2013 08:14, "Terry Reedy" <tjreedy at udel.edu> wrote:
> 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
> 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.
I realised last night that "labelled values" might be a better building
block than "named values".
I'll see if I can find my old python-ideas posts about the concept
(although, to be honest, I'm not sure it has ever been elaborated much
further than it has in this thread)
> 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)')
> plus 3 lines for seek.
> Terry Jan Reedy
> Python-Dev mailing list
> Python-Dev at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev