[Python-ideas] Syntax for easy binding __name__, __module__, __qualname__ to arbitrary objects

[Steven D'Aprano]

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 at 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 at gmail.com> wrote:
> >>> On May 9, 2013, at 3:29 AM, Piotr Duda <duda.piotr at 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