
Two things that were suggested in private:
1) ask users to pass the module name to the convenience function explicitly (i.e. pass "seasonmodule.Season" instead of "Season" as
On Thu, 2 May 2013 13:15:00 -0700 Eli Bendersky <eliben@gmail.com> wrote: the
class "name"). Guido doesn't like it :-)
2) dicth the "convenience function" and replace it with a regular class-based syntax. Ethan doesn't like it :-)
Re (2), we already have the hack in stdlib in namedtuple, so not allowing it for an enum is a step backwards.
That's a fallacy. There is no step backwards if you adopt a class-based syntax, which is just as convenient as the proposed "convenience function". I have a hard time understanding that calling a function to declare a class is suddenly considered "convenient".
If sys._getframe(1).f_globals['__name__'] feels hackish, maybe it can be shortened to a convenience function the stdlib provides?
It's not the notation which is hackish, it's the fact that you are inspecting the frame stack in the hope of getting the right information.
What if someone wants to write another convenience function that wraps your convenience function? What if your code is executing from some kind of step-by-step debugger which inserts an additional frame in the call stack? What if someone wants the enum to be nested inside another class (rather than reside at the module top-level)?
Would nesting the non-convenience Enum in a function or a class allow one to pickle it?
Once PEP 3154 is implemented (Alexandre is on it :-)), nested classes should be picklable.
Interesting, I did not know that.
As for classes inside functions, it sounds quite impossible (how do you instantiate the function namespace without calling the function?).
True. Back to my question from before, though - do we have a real technical limitation of having something like inspect.what_module_am_i_now_in() that's supposed to work for all Python code? Eli