I'm currently developing an application that needs to execute code from a library in a way that gives each call into that system access to a set of call-specific variables. The problem is that I can't change the library all that much, e.g. add some context parameter to all calls, so I have to use some other technique for accessing the call-specific variables. I've come up with a trick that uses Python call stacks which works quite well. My only concern is whether this technique will continue to work in future versions of Python. Here's the helper I'm using: import sys def acquire_from_call_stack(varname): # Start from the caller of the function calling this helper frame = sys._getframe(2) while frame is not None: if frame.f_locals.has_key(varname): value = frame.f_locals[varname] frame = None return value frame = frame.f_back raise AttributeError, varname Any idea as to what might happen to stack frames in the future ? -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Aug 01 2003)
Python/Zope Products & Consulting ... http://www.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
Everything you use appears to be documented in the Python Language Reference, ("Frame Objects" in "Internal Types"), and the heading of that section explicitly states that these may change in future versions of the interpreter. So, while you are theoretically not safe in practice you are probably reasonably safe. sys.exc_traceback is also still there, even though sys.exc_info() was added 5 years ago as the preferred interface. On Friday, Aug 1, 2003, at 15:06 Europe/Amsterdam, M.-A. Lemburg wrote:
I'm currently developing an application that needs to execute code from a library in a way that gives each call into that system access to a set of call-specific variables.
The problem is that I can't change the library all that much, e.g. add some context parameter to all calls, so I have to use some other technique for accessing the call-specific variables.
I've come up with a trick that uses Python call stacks which works quite well. My only concern is whether this technique will continue to work in future versions of Python. Here's the helper I'm using:
import sys
def acquire_from_call_stack(varname):
# Start from the caller of the function calling this helper frame = sys._getframe(2) while frame is not None: if frame.f_locals.has_key(varname): value = frame.f_locals[varname] frame = None return value frame = frame.f_back raise AttributeError, varname
Any idea as to what might happen to stack frames in the future ?
-- Marc-Andre Lemburg eGenix.com
Professional Python Software directly from the Source (#1, Aug 01 2003)
Python/Zope Products & Consulting ... http://www.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
_
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev
--
Jack Jansen,
Jack Jansen wrote:
Everything you use appears to be documented in the Python Language Reference, ("Frame Objects" in "Internal Types"), and the heading of that section explicitly states that these may change in future versions of the interpreter. So, while you are theoretically not safe in practice you are probably reasonably safe. sys.exc_traceback is also still there, even though sys.exc_info() was added 5 years ago as the preferred interface.
Thanks (perhaps we should add more such notes to the spec, to make sure they still exist another 5 years down the road :-). -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Aug 01 2003)
Python/Zope Products & Consulting ... http://www.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
Martin v. Löwis wrote:
"M.-A. Lemburg"
writes: The problem is that I can't change the library all that much, e.g. add some context parameter to all calls, so I have to use some other technique for accessing the call-specific variables.
I recommend to use thread-local variables.
Thanks, but that only works in multi-threaded environments where you process each call in a different thread. This application is single-threaded (even though it may turn into a multi-threaded one at some later stage). -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Aug 01 2003)
Python/Zope Products & Consulting ... http://www.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
"M.-A. Lemburg"
I recommend to use thread-local variables.
Thanks, but that only works in multi-threaded environments where you process each call in a different thread. This application is single-threaded (even though it may turn into a multi-threaded one at some later stage).
That is not true. In the single-threaded case, just use global variables. Regards, Martin
Martin v. Löwis wrote:
"M.-A. Lemburg"
writes: I recommend to use thread-local variables.
Thanks, but that only works in multi-threaded environments where you process each call in a different thread. This application is single-threaded (even though it may turn into a multi-threaded one at some later stage).
That is not true. In the single-threaded case, just use global variables.
... and then manage access to these global variables ? No thanks. I always try to keep global state in objects so that a later transition to a multi-threaded application remains easily possible. I'll stick with my solution for the time being. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Aug 02 2003)
Python/Zope Products & Consulting ... http://www.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
participants (3)
-
Jack Jansen
-
M.-A. Lemburg
-
martin@v.loewis.de