[Python-Dev] PEP 435: pickling enums created with the functional API

Ethan Furman ethan at stoneleaf.us
Tue May 7 18:07:45 CEST 2013

On 05/07/2013 08:03 AM, Nick Coghlan wrote:
> On Tue, May 7, 2013 at 11:34 PM, Eli Bendersky wrote:
>> 4) Using _getframe(N) here seems like an overkill to me.
> It's not just overkill, it's fragile - it only works if you call the
> constructor directly. If you use a convenience function in a utility
> module, it will try to load your pickles from there rather than
> wherever you bound the name.
>> What we really need
>> is just the module in which the current execution currently is (i.e. the
>> metaclass's __new__ in our case). Would it make sense to add a new function
>> somewhere in the stdlib of 3.4 (in sys or inspect or ...) that just provides
>> the current module name? It seems that all Pythons should be able to easily
>> provide it, it's certainly a very small subset of the functionality provided
>> by walking the callframe stack. This function can then be used for build
>> fully qualified names for pickling of Enum and namedtuple. Moreover, it can
>> be general even more widely - dynamic class building is quite common in
>> Python code, and as Nick mentioned somewhere earlier, the extra power of
>> metaclasses in the recent 3.x's will probably make it even more common.

Perhaps I am being too pendantic, or maybe I'm not thinking in low enough detail, but it seems to me that the module in 
which the current execution is is the module in which the currently running code was defined.

What we need is a way to get where the currently running code was called from.

And to support those dreaded utility functions, a way to pass along where you were called from so the utility function 
can lie and say, "Hey, you! Yeah, you Enum!  You were called from app.main, not app.utils.misc!"


More information about the Python-Dev mailing list