On 7/8/06, Tim Peters <tim.peters at gmail.com> wrote: > > Back in: > > http://mail.python.org/pipermail/python-dev/2005-March/051856.html > > I made a pitch for adding: > > sys._current_frames() > > to 2.5, which would return a dict mapping each thread's id to that > thread's current (Python) frame. As noted there, an extension module > exists along these lines that's used at least by the popular Zope > DeadlockDebugger product, but it's not possible to do it correctly in > an extension. The latter is why it needs to be in the core (so long > as it's in an extension, it risks segfaulting, because the core's > internal `head_mutex` lock isn't exposed). > > I forgot about this but was recently reminded. How much opposition > would there be to sneaking this into 2.5b2? It would consist of > adding a relatively simple new function, docs, and tests; since it > wouldn't _change_ any existing code, it would have a hard time > breaking anything that currently works. Well, my understanding is that beta is feature freeze, so I am going to say we shouldn't do this. Obviously this can go in day one when 2.6 is started. Anyway, this is a true test of how rigid the rules are! Can Neal and Anthony going to say no to Uncle Timmy? =) -Brett -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-dev/attachments/20060708/a8240a7a/attachment.htm
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4