[Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library (original) (raw)
Glenn Linderman v+python at g.nevcal.com
Fri Apr 26 05:06:03 CEST 2013
- Previous message: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
- Next message: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 "", 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 modulecontainingcolor modulecontainingcolor.Color.exportenumerations( globals ) or import modulecontainingcolor modulecontainingcolor.Color.exportenumerations( locals ) Or maybe locals is implicit, and in the file scope of a module, locals are globals anyway, so doing modulecontainingcolor.Color.exportenumerations() 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>
- Previous message: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
- Next message: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]