Re: [Python-ideas] adopt an enum type for the standard library?
[Mark Summerfeld]
I think enums are a common enough requirement to be worth adding to the standard library---not to the language.
-1 This is clutter. Also, I disagree about there being a need. We've long been able to roll our own with a simple class definition (like the first example shown below), but people rarely do that. They don't want to pay the cost in speed (for the attribute lookup) and find that all the prefixed references make their code look more Javaesque that Pythonesque. Over years of looking at tons of Python code, I've seen several variants of enums. In *every* case, they were just a toy recipe and were not be used in anything other than demo code. I know it's possible to invent use cases for this, but I think real world needs have largely been met through module and class namespaces. If you have a lot of constants, the simple approach is to put them in their own module and then reference them using mod.name. If there are a medium number, then a class namespace (like the first example below) may be preferable. If there are only a few, the people seem to be happy with globals. Something like "wheres= Enum( UP= 0, DOWN= 0, LEFT= 0, RIGHT= 0 )" is easily written as: class wheres: UP = 0; DOWN = 0; LEFT = 0; RIGHT = 0 Or equivalently: wheres = type('wheres', (), dict(UP= 0, DOWN= 0, LEFT= 0, RIGHT= 0 )) Or using the module approach: -- wheres.py -- UP = 0; DOWN = 0; LEFT = 0; RIGHT = 0 --- mymod.py -- import wheres prints where.UP Or using globals approach and avoid the attribute lookup: UP = 0; DOWN = 0; LEFT = 0; RIGHT = 0 There are already so many reasonable ways to do this or avoid doing it, that it would be silly to add an Enum factory. IMO, Enum() is in the category of recipes that are like variants of flatten() or Sudoku solvers; they are fun to write but no one really needs them. not-everything-in-the-cookbook-needs-to-be-in-the-library-ly yours, Raymond
On 2008-01-24, Raymond Hettinger wrote:
[Mark Summerfeld]
I think enums are a common enough requirement to be worth adding to the standard library---not to the language.
-1 This is clutter.
Also, I disagree about there being a need. We've long been able to roll our own with a simple class definition (like the first example shown below), but people rarely do that. They don't want to pay the cost in speed (for the attribute lookup) and find that all the prefixed references make their code look more Javaesque that Pythonesque.
Over years of looking at tons of Python code, I've seen several variants of enums. In *every* case, they were just a toy recipe and were not be used in anything other than demo code.
Did you also see lots of examples of people creating their own set types? Until something is part of the language or library people will toy with their own version but probably won't commit to it. But once something is standardised it gets used---if it is general purpose. For example, I use sets all the time now, but they are a relatively new feature in Python, so before I often had dicts with None values. [snipped examples]
There are already so many reasonable ways to do this or avoid doing it, that it would be silly to add an Enum factory.
I thought that one of Python's strengths was supposed to be that in general there is just one best way to do things.
IMO, Enum() is in the category of recipes that are like variants of flatten() or Sudoku solvers; they are fun to write but no one really needs them.
None of the examples you gave provides any level of const-ness. Yet namedtuple's and tuples do. And an enum factory function for collections could be as simple as: def enum(field_names, values=None): e = collections.namedtuple("_enum", field_names) if values is None: values = range(len(field_names.split())) return e(*values) (Although this doesn't account for pickling.)
Vehicle = enum("car van bus truck") Vehicle.car, Vehicle.van, Vehicle.bus, Vehicle.truck (0, 1, 2, 3) Limit = enum("minimum maximum default", (-50, 50, 10)) Limit.default 10
-- Mark Summerfield, Qtrac Ltd., www.qtrac.eu
Over years of looking at tons of Python code, I've seen several variants of enums. In *every* case, they were just a toy recipe and were not be used in anything other than demo code.
[Mark Summerfeld]
Did you also see lots of examples of people creating their own set types?
Until something is part of the language or library people will toy with their own version but probably won't commit to it. But once something is standardised it gets used---if it is general purpose.
This is true. Unfortunately, it means that if you add something to the language that shouldn't be there, it will get used also. When a tool is present, it suggests that the language designers have thought it through and are recommending it. It then takes time and experience to unlearn the habit (for example, it takes a while to learn that pervasive isinstance() checks get in the way of duck typing). This is doubly true for features that are found in compiled languages but of questionable value in a dynamic language. IMO, the hardest thing for a Python newbie is to stop coding like a Java programmer.
There are already so many reasonable ways to do this or avoid doing it, that it would be silly to add an Enum factory.
I thought that one of Python's strengths was supposed to be that in general there is just one best way to do things.
It's strange that you bring that up as argument for adding yet another type of namespace.
None of the examples you gave provides any level of const-ness.
That is not a virtue. It is just psuedo const-ness. It is dog slow and not compiled as a constant. All you're getting is something that is harder to write to. That doesn't make sense in a consenting adults environment. Take a look through the standard library at how many times we make an attribute read-only by using property(). It is just not our style. BTW, the rational module needs to undo that choice for numerator and denominator. It makes the code slow for basically zero benefit. [Jonathan Marshall]
we find that experienced python programmers are use to the absence of a standard enum type but new python programmers are surprised by its absence
I think this is a clear indication that new programmers all wrestle with learning to write Pythonically instead of making shallow translations of code they would have written in statically compiled languages. Adding something like Enum() will only reinforce those habits and slow-down their progress towards becoming a good python programmer. Raymond
Something like "wheres= Enum( UP= 0, DOWN= 0, LEFT= 0, RIGHT= 0 )" is easily written as:
class wheres: @staticmethod def reassign(): wheredir= [ v for v in dir( wheres ) if not callable( getattr( wheres, v ) ) and not v.startswith( '_' ) ] for i, v in enumerate( wheredir ): setattr( wheres, v, i ) UP = 0; DOWN = 0; LEFT = 0; RIGHT = 0 wheres.reassign()
We typically reassign enum values once they're assigned, and sometimes just add new ones. I tend to write new classes where I think people use enums. 20% longer code; 80% fewer ifs. [1] [1] http://en.wikipedia.org/wiki/Visitor_pattern
participants (3)
-
Aaron Brady -
Mark Summerfield -
Raymond Hettinger