On Tue, May 7, 2013 at 9:14 AM, Antoine Pitrou <solip...@pitrou.net> wrote:
> Le Tue, 7 May 2013 08:44:46 -0700, > Eli Bendersky <eli...@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
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
