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

[Eli Bendersky]

On Tue, May 7, 2013 at 9:14 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:

> Le Tue, 7 May 2013 08:44:46 -0700,
> Eli Bendersky <eliben at gmail.com> a écrit :
> > >  > 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.
> >
> > In theory you can climb the frame stack until the desired place, but
> > this is specifically what my proposal of adding a function tries to
> > avoid.
>
> I don't know how you could do it without walking the frame stack.
> Granted, you don't need all the information that the stack holds
> (you don't need to know about line numbers, instruction numbers
> and local variables, for instance :-)), but you still have to walk
> *some* kind of dynamically-created stack. This isn't something
> that is solvable statically (as opposed to e.g. a class's __qualname__,
> which is computed at compile-time).
>

Yes, I fully realize that. I guess I should have phrased my reply
differently - this is what the proposal helps *user code to avoid*. For
CPython and PyPy and Jython it will be perfectly reasonable to actually
climb the frame stack inside that function. For IronPython, another
solution may be required if no such frame stack exists. However, even in
IronPython there must be a way to get to the module name?

In other words, the goal is to hide an ugly piece of exposed implementation
detail behind a library call. The library call can be implemented by each
platform according to its own internals, but the user won't care.

Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130507/f4b5ecdb/attachment.html>