[Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
Glenn Linderman
v+python at g.nevcal.com
Fri Apr 26 05:06:03 CEST 2013
On 4/25/2013 7:25 PM, Ethan Furman wrote:
> On 04/25/2013 07:09 PM, Glenn Linderman wrote:
>> On 4/25/2013 4:53 PM, Ethan Furman wrote:
>>> On 04/25/2013 04:26 PM, Glenn Linderman wrote:
>>>> My question is, once an enumeration is defined, is there a way,
>>>> short of element-by-element assignment, to import the
>>>> individual enumeration instances into the current namespace, so
>>>> that I can say "red" instead of "Color.red" ? I
>>>> understand the benefits of avoiding name collisions when there are
>>>> lots of enumerations, and lots of opportunities for
>>>> name collections between, say, RGBColor and CYMKColor... but there
>>>> are lots of uses for enumerations where the
>>>> subsidiary namespace is just aggravating noise.
>>>
>>> You mean something like:
>>>
>>> --> class Color(Enum):
>>> ... RED = 1
>>> ... GREEN = 2
>>> ... BLUE = 3
>>>
>>> --> Color.register() # puts Color in sys.modules
>>>
>>> --> from Color import * # doesn't work in a function, though :(
>>>
>>> --> BLUE
>>> Color.BLUE
>>
>> Something like that, but that works in a function too :)
>
> Not in Py3 it doesn't:
Parse error. "Something like that, but something like that that works
in a function too :)" is what I meant. I understand that the feature
you demonstrated doesn't work in Py3... that's why we need "something
like that" rather than "that" :)
>
> Python 3.2.3 (default, Oct 19 2012, 19:53:16)
> [GCC 4.7.2] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> --> def test():
> ... from sys import *
> ... print('huh')
> ...
> File "<stdin>", line 1
> SyntaxError: import * only allowed at module level
>
>
>>> Yeah, that would be nice. ;) A bit dangerous, though -- what if
>>> another module does the same thing, but its Color
>>> is different?
>>>
>>> Better would be:
>>>
>>> --> Color.export(globals()) # put the enumerators in globals
>>>
>>> --> RED
>>> Color.RED
>>
>> Globals? locals should be possible too.
>
> At least in Cpython, updating locals() does not work in functions.
>
>> Or even something like:
>>
>> with Color:
>> BLUE
>> RED
>>
>> Although the extra indentation could also be annoying.
>>
>> One wouldn't want the module defining Color to automatically 'export'
>> the colors: but rather a way to request an
>> 'export' them into a particular scope. That way the proliferation of
>> names into scopes is chosen by the programmer.
>>
>> import module_containing_color
>> module_containing_color.Color.export_enumerations( globals )
>>
>> or
>>
>> import module_containing_color
>> module_containing_color.Color.export_enumerations( locals )
>>
>> Or maybe locals is implicit, and in the file scope of a module,
>> locals are globals anyway, so doing
>>
>> module_containing_color.Color.export_enumerations()
>
> locals() can't be implicit, at least not without deep black magic of
> inspecting frames in the call stack -- which is hardly portable.
So what I'm hearing is that enumerations need to be a language feature,
rather than a module:
Can't combine Enum and EnumItem
Can't import into locals
The compiler could do those things, though.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130425/6ffae882/attachment.html>
More information about the Python-Dev
mailing list