[Python-Dev] constant/enum type in stdlib

Raymond Hettinger raymond.hettinger at gmail.com
Wed Nov 24 03:35:35 CET 2010


On Nov 23, 2010, at 3:41 PM, Greg Ewing wrote:

> While it may be possible to work around these things with
> sufficient levels of metaclass hackery and black magic, at
> some point one has to consider whether new syntax might
> be the least worst option.

The least worst option is to do nothing at all.
That's better than creating a new little monster with its 
own nuances and limitations.

We've gotten by well for almost two decades without
this particular static language feature creeping into Python.

For the most part, strings work well enough (see
decimal.ROUND_UP for example).  They are self-documenting
and work well with the rest of the language.

When a cluster of names cries out for its own namespace,
the usual technique is to put the names in class (see the examples
in the namedtuple docs for a way to make this a one-liner) 
or in a module (see opcode.py for example).

For xor'able and or'able flags, sets of strings work well:
   flags = {'runnable', 'callable'}
   flags |= {'runnable', 'kissable'}
   if 'callable' in flags:
      . . .

We have a hard enough time getting people to not program
Java in Python.  IMO, adding a new enumeration type
would make this situation worse.  Also, it adds weight to
the language -- Python is not in needs of yet another fundamental
construct.


Raymond


P.S.  I do recognize that lots of people have written their own
versions of Enum(), but I think they do it either out of habits formed
from statically compiled languages that lack all of our namespace
mechanisms or they do it because it is easy and fun to write
(just like people seem to enjoy writing flatten() recipes more
than they like actually using them).

One other thought:  With Py3.x, the language had its one chance
to get smaller.  Old-style classes were tossed, some built-ins 
vanished, and a few obsolete modules got nuked.  It would be
easy to have a "let's add thingie x" fest and lose those benefits.
There are many devs who find that the language does not 
fit-in-their-heads anymore, so considerable restraint needs to
be exercised before adding a new language feature that would
soon permeate everyone's code base and add yet another thing
that infrequent users have to learn before being able to read code.






More information about the Python-Dev mailing list