Mark Summerfield added the comment:
Nice answer Ethan (but I can't vote you up since stack overflow won't let me
vote or even comment anymore).
As for adding export_to(), it seems like a good idea. However, personally, I
think the signature should be
hoist_into(namespace, cls, *clses)
Mark Summerfield added the comment:
Since this is a bit controversial, I've tried marking it as 'rejected' with
this comment.
I've also added a very brief explanation and link back to here on my web site:
http://www.qtrac.eu/pyenum.html
--
resolution: - rejected
Changes by Mark Summerfield m...@qtrac.eu:
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23292
___
___
Python-bugs-list
Ethan Furman added the comment:
Amusingly enough, I posted a question/answer to StackOverflow
(http://stackoverflow.com/q/28130683/208880) and so far the only other
respondent posted an answer with similar functionality to my own, and also
recommended that such a method be added to the base
Eli Bendersky added the comment:
Georg, each library writer is entitled to do whatever she wants. Naturally, we
can't prevent dumping contents of enums into the module namespaces, and yes,
backwards compatibility makes sense for some modules.
However, that's tangential to *encouraging* this
Georg Brandl added the comment:
Likewise, I don't feel strongly that it *should* go in, but I wouldn't object
to it.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23292
___
Eli Bendersky added the comment:
I'm not sure why the current situation is annoying?
Python explicitly does not pollute the enclosing namespace with an Enum's
members. So when you:
import A
It's fairly natural that you have access to A.MyEnum and not its members, no?
Some modules (like some
Georg Brandl added the comment:
I disagree. I assume that many new enums will be a replacement for module-level
constants, but these still have to be available on the module. Keeping backward
compatibility is not against the spirit of Python :)
--
Serhiy Storchaka added the comment:
Agree with Eli.
--
nosy: +serhiy.storchaka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23292
___
___
Ethan Furman added the comment:
Currently the way to add an Enum's members to a module's namespace is:
globals().update(MyEnumeration.__members__)
but that seems quite ugly. Is there anywhere else that the user is required to
use __xxx__ methods for common functionality?
I think a new
Georg Brandl added the comment:
Well, for such operations (namespace manipulation) __dict__ is also often used,
so I wouldn't say it's too ugly.
--
nosy: +georg.brandl
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23292
Mark Summerfield added the comment:
Georg said to assign this to Ethan Furman but I don't seem to have that
facility.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23292
___
New submission from Mark Summerfield:
I think it would be worth documenting
globals().update(MyEnumeration.__members__) in the Interesting
Examples section of the enum docs.
I suspect that most people will find that importing enums is annoying
because they'll get
import A
Changes by Georg Brandl ge...@python.org:
--
assignee: docs@python - ethan.furman
nosy: +ethan.furman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23292
___
14 matches
Mail list logo
