Verifiably better, validated Enum for Python

[bartc]

On 24/05/2017 15:31, Steve D'Aprano wrote:

> Same as if Python supported constants (names that can only be assigned to
> once).

That's not quite the same as my notion of 'named constant' that I expand 
below. This suggests that the actual literal bound to the name may not 
be known until runtime.

> Again, the pain of building a custom "constant-like" solution is
> greater than the benefit, so I've done without.
>
> But if Python did support these things, maybe the compiler could make a few
> optimizations, or maybe we could write a few less unit tests, or catch a
> few bugs a little earlier... or not.
>
>
> It's just a different way at looking at minimalism. Guido says, the language
> should be as small as possible.

A funny way of making things minimal when people are then obliged to 
create dozens of different add-on libraries to try and add the missing 
functionality. It doesn't make the language any faster either when the 
solutions involve extra modules, classes, attribute lookups and type
dispatching.

Anyway, my Python 3.4 comprises 5000 files in around 90MB. Minimalism 
hasn't really worked.

> If you don't want to assign to a name, then
> just don't assign to it. No need to build support for constants into the
> language when you can trust the developer to Don't Do That.

Yet the language will stop you assigning to 672, or "abc" (Had to do a 
quick that that was actually the case! Python is full of surprises.)

Maybe the language could have been made even smaller if that was not 
checked; after all the developer ought to be trusted not to assign to them!

Well, named constants are just such literals, but with a name. The 
design of Python however means that that immediately causes a difficult 
because then we have to deal with different scopes, name lookups, and 
named constants defined inside a module or class so requiring an 
attribute lookup.

Ideally a named constant would be instantly mapped to the equivalent 
literal, and done during compilation. Then a range of optimisations also 
become possible (and enables a fast 'switch' statement).

-- 
bartc