Last chance! (was: Does anybody really use frame->f_tstate ?)

[Christian Tismer]

Dear Python community,

since I didn't get *any* reply to this request,
either the request was bad or there is really
nobody using f_tstate in a way that makes it
urgent to keep.
I will wait a few hours and then make the change
to Stackless, and I'd like to propose to do the
same to the Python core.

Christian Tismer wrote:

Hi colleagues,

this is my second attempt to get rid of the f_tstate field
in frames. I need to find every user of this field.

What am I talking about?
Well, Python always has a thread state variable which
is a unique handle to the current thread. This variable
is accessed in many places, and there exists a fast macro
to get at it.
Every executing Python frame also gets a copy on creation.
In some cases, this frame->f_tstate field is used,
in other cases the current tstate variable is used.

If this sounds foreign to you, please stop reading here.

-------------------------------------------------------------

I would like to get rid of the frame->f_tstate, and I'm trying
to find out if there is a need for it. I don't need it,
for Stackless, it is the opposite, it disturbs.

There was a small thread about this in June this year, where
Guido convinced me that it is possible to create a traceback
on a frame that comes from a different thread.

http://mail.python.org/pipermail/pyt...ne/036254.html

Ok, this is in fact possible, although I don't think
anybody has a need for this.

My question to all extension writers is this:
If you use frame->f_tstate at all, do you use it just
because it is handy, or do you want to use it for
some other purpose?

One purpose could be that you really want to create a traceback
on a different than the current thread. I have never seen this,
but who knows, so that's why I'm asking the Python world.

In most cases, a traceback will be created on a frame
that is currently processd or just has been processed.
Accessing a frame of a different thread that is being processed
might make sense for special debugger cases.

My proposal is
--------------

a) change semantics of PytraceBack_Her e to use the current tstate.

b) if such a special purpose exists, create a new function for it.

c) if urgent, different needs exist to keep f_tstate,
then let's forget about this proposal.

Especially for Stackless, I'd be keen of getting rid of this.

thanks for input -- chris

--
Christian Tismer :^) <mailto:ti****@ tismer.com>
Mission Impossible 5oftware : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work [phone] home [phone] mobile [phone]
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/