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

[Jim Jewett]

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.

> 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 ...

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.


>> is that you might accidentally type ...

>   >>> Anmals = Enum('Animals', 'dog cat bird')

> In which case, either something will break, and you will fix the broken
> code, and then it will work, or nothing will break, in which case it almost
> certainly doesn't matter and you can pretend you did it on purpose.

I regularly maintain Java (and formerly C) code in which a name was
misspelled, or even just spelled oddly.*  The code works, so long as
other code is sufficiently consistent, but it is a lot harder to maintain.
(That said, *most* of the extra problems are from grep not finding the
code, which wouldn't be a problem for this *particular* case -- at least
not until some other tool started using the class name for pickling or
documentation or something.)

* "oddly" can even mean "correctly", if the project otherwise uses
abbreviations.

-jJ