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.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
