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>
