This patch adds a new function sys._getframes() that 
returns a dictionary mapping from thread id to 
current frame object.

This is very useful when diagnosing deadlock issues 
in Python code.

The new C code function is purely additive except for 
modifying the PyThreadState struct (adding a long 
thread_ident) and modifying PyThreadState_New() 
function to set this new long.

Logged In: YES 
user_id=21627

I think the patch could use some more documentation, e.g. 
as a patch to Doc/lib/libsys.tex. E.g. what are the tuples 
that are put into the dictionaries?

Also, isn't there a problem with the tuple size? The patch 
allocates tuples of size 0, but then puts things into 
index 0. Is there any kind of test case for this code?

Finally, I don't think the docstring should say that the 
function is for internal and specialized purposes only 
(what specialized purposes, anyway), if you think its 
primary use is in diagnosing deadlocks. It should only 
document what the function does, not what you intend it to 
use for.

For these reasons, I also think its name should not start 
with an underscore.

Logged In: YES 
user_id=20438

Martin:  I agree with you on the documentation issue and 
will look into the tuple size issue you raised.

The docstring is modeled on the sys._getframe() function 
so I figured it would be sufficient to follow the leader.

(I think that both sys._getframe() and sys._getframes() 
should be part of the public api for the sys module by the 
way.)

Logged In: YES 
user_id=21627

There is a difference between these two functions. _getframe
is not an
official API; inspect.currentframe is the official API. It
seems that
your function is meant to be used via sys, so it would be
public
there.

In any case, I also think that  the sys._getframe doc string
should
not talk about intended uses - if anything, it should
mention what
function to call instead.

Logged In: YES 
user_id=21627

I propose to close this patch if it is not updated by Oct 
1, 2001. If it is not updated by the time the last alpha 
is released, it probably has no chance to go into Python 
2.2.

Logged In: YES 
user_id=12800

In keeping with Martin's last comment, I'm closing this
patch.  If the issues brought up are addressed, we can
re-evaluate it for Python 2.3.