Verifiably better, validated Enum for Python

Ian Kelly ian.g.kelly at gmail.com
Wed May 24 18:25:32 EDT 2017


On Wed, May 24, 2017 at 4:11 PM, bartc <bc at freeuk.com> wrote:
> On 24/05/2017 15:31, Steve D'Aprano wrote:
>> 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!

Probably not, because then code would have to be written to implement
assigning to something that isn't an identifier. In Python's data
model I don't know what that would even mean.

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

What if you want to define a named constant that isn't a literal? For example:

const LOCALHOST = IPAddress('127.0.0.1')



More information about the Python-list mailing list