On Tue, May 14, 2013 at 06:43:10PM -0400, Jim Jewett wrote:
On Mon, May 13, 2013 at 9:42 PM, Steven D'Aprano <steve@pearwood.info> wrote:
On 14/05/13 01:49, Jim Jewett wrote:
On Sun, May 12, 2013 at 9:33 PM, Raymond Hettinger <raymond.hettinger@gmail.com> wrote:
On May 9, 2013, at 3:29 AM, Piotr Duda <duda.piotr@gmail.com> wrote:
Animals = Enum('Animals', 'dog cat bird') which violates DRY
This is a profound misreading of DRY which is all about not repeating big chunks of algorithmic logic.
DRY, like most heuristics, is about making mistakes less likely.
Mistakes are likely with huge chunks of repeated logic, because people are inclined to fix things at only one location.
Mistakes are likely with the above because it is conceptually only one location, but syntactically two -- and doing something different in the second location is a mistake that the compiler won't catch.
"Likely"? I think not.
If you (generic "you", not you personally) are such a careless coder that you are *likely* to mistype the name in a *single line* like `name = Enum("name", "items...")` then there is probably no help for you. Mistakes happen to the best of us, but they are *rare*.
Likely relative to other my other mistakes, yes.
I see what you did there :-) But seriously, *in my experience*, mere typos of names are not usually critical errors. They are usually discovered and fixed immediately when the code raises a NameError. So I have little (not zero, but *little*) concern about the risk of typos like: Animals = Enum("Animal", "cow dog cat sheep") Chances are that you will detect this immediately you try to run the code, when Animal.cow raises NameError. Either way though, it's an easy error to fix, and an easy mistake for a linter to check. So why I acknowledge that *in principle* this is a weakness of Python that can lead to bugs, it is my opinion that *in practice* it is close enough to harmless that there's no reason to rush into a sub-optimal fix for it.
Besides, strictly speaking setting the Enum name different to the name being bound is not necessarily an error. We can, and frequently do, define functions with one name and then bind them to a different name, e.g. in decorators.
If the name didn't need to match, then you could just as well use strings and retype them everywhere. It would be caught (or not) in testing ...
The advantage of having Animal.cow, Animal.dog etc. is to standardise on the cow and dog parts, not the Animal part. Animal is mostly just the container, it is the enums that you usually care about. For many purposes, we won't even care about the container. We'll do something like this: Directions = Enum("Directions", "UP DOWN LEFT RIGHT") globals().update(Directions.members()) (have I got the name "members" right?) and then always refer to UP, DOWN etc. directly. If we don't care about pickling the enums, and do care about "namespace pollution", we might even `del Directions` and be done with it.
Wanting to ensure that typos don't slip in -- even to documentation-only sections -- is much of the motivation for enums, as well as for the recurrent calls for a make statement.
I agree. Having to type the class name twice is a wart. But it's not a big one. More of a pimple. -- Steven