[Python-Dev] constant/enum type in stdlib (original) (raw)

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