[Python-Dev] Re: Useful thread project for 2.5?

[Tim Peters]

[Fazal Majid]
> Since I started this, I might as well finish it. I do have some Python
> developer experience (hey, I even voted for comp.lang.python back
> when...) but not in the core interpreter itself.

Cool!  WRT your current module, it would need changes to follow
Python's C coding style, to check _every_ C API call for an error
return, and to grab head_mutex while crawling over the tstate chain.

> I suspect integrating this feature (let's call it sys._current_frames()
> for the sake of argument, although it probably belongs in the threads
> module)

I expect that Phillip's thought here is that the sys module already
has a _getframe() function, so everyone who knows that would likely
expect a new frame-retrieval function to be exposed in sys too.

> in the core is not going to be quite as trivial as you say, as there are
> potential memory leaks.

Good news:  I don't think so.

> If the function returns a dictionary, it should probably be a weak dict to avoid
> a circular reference between the frame of the thread that calls _current_frames
> and its locals that contain the returned dictionary. But that would also mean the
> references to other threads' frames are going to be weak, thus not allowing the
> current thread to inspect their locals and backtraces at will as those weak
> references may be broken.

dicts and frames both participate in cyclic gc in recent Pythons.  For
example, you can run this all day in 2.4 and not see memory grow
(provided you don't disable cyclic gc):

def f():
    import sys
    myframe = sys._getframe()

while 1:
    f()

Frames aren't weakly referenceable anyway:

>>> import weakref
>>> import sys
>>> f = sys._getframe()
>>> weakref.ref(f)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: cannot create weak reference to 'frame' object