RetroSearch Browse

Fri Apr 26 05:06:03 CEST 2013 · https://mail.python.org/pipermail/python-dev/2013-April/125583.html

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>

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2013-April/125583.html below:

[Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library