Tim Peters wrote:
Just to make life harder ;-), I should note that code, docs and tests
for sys._current_frames() are done, on the tim-current_frames branch.
All tests pass, and there are no leaks in the new code. It's just a
NEWS blurb away from being just another hectic release memory :-)
On Sun, 9 Jul 2006 20:45:05 -0700, Neal Norwitz wrote:
There hasn't been much positive response (in the original thread or
here). Given you forgot about it for over a year, how important can
it be? :-)
For me it would be very important because I often wonder where the threads
are currently
[Neal Norwitz]
There hasn't been much positive response (in the original thread or
here).
Do note that there was little response of any kind, but all it got was
positive. It's not sexy, but is essential for debugging deadlocks.
If you ask for positive response, you'll get some -- the use is
+1
On 7/10/06, Raymond Hettinger [EMAIL PROTECTED] wrote:
Tim Peters wrote:
[Neal Norwitz]
There hasn't been much positive response (in the original thread or
here).
Do note that there was little response of any kind, but all it got was
positive. It's not sexy, but is essential for
On Tuesday 11 July 2006 06:16, Raymond Hettinger wrote:
FWIW, I think this patch should go in. The benefits are
obvious and real.
Yep. I'm going to check it in, unless someone else beats me to it in
the next couple of hours before the b2 freeze.
But, the imagined costs of a new feature
[Raymond]
FWIW, I think this patch should go in. The benefits are
obvious and real.
[Anthony Baxter]
Yep. I'm going to check it in, unless someone else beats me to it in
the next couple of hours before the b2 freeze.
I'll merge it from my branch right after I send this email. It still
needs
On Tuesday 11 July 2006 06:52, Tim Peters wrote:
I don't think trying to produce the most stable and bugfree
Python possible could in _anyway_ be considered pedantry, and
it makes me quite grumpy to have it described in that way.
He meant that no new features, while a useful guideline, can
Anthony Baxter wrote:
But, the imagined costs of a new feature
during beta are illusory.
This, I cannot agree with. The costs and risks of just continuing to
add new features all through the release process are high.
I meant this particular feature.
In general, there
[Scott Dial]
Wouldn't this function be better named sys._getframes since we already
have a sys._getframe for getting the current frame?
http://mail.python.org/pipermail/python-dev/2005-March/051887.html
The first only name suggested won. As it says there, I usually have
no appetite for
Tim Peters 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
On Sunday 09 July 2006 11:31, Tim Peters 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
On 09/07/2006, at 9:05 AM, Anthony Baxter wrote:
I'm really not keen on this seeming tide of new features wink that
seem to be popping up. We're only a few days away from the second and
final planned beta - it's getting _awfully_ late to be slotting in
new features.
And besides, one person
Richard Jones wrote:
On 09/07/2006, at 9:05 AM, Anthony Baxter wrote:
I'm really not keen on this seeming tide of new features wink that
seem to be popping up. We're only a few days away from the second and
final planned beta - it's getting _awfully_ late to be slotting in
new features.
[Anthony Baxter]
Hm. Would it be a smaller change to expose head_mutex so that the
external module could use it?
No, in part because `head_mutex` may not exist (depends on the build
type). What an external module would actually need is 3 new public C
API functions, callable workalikes for
Just to make life harder ;-), I should note that code, docs and tests
for sys._current_frames() are done, on the tim-current_frames branch.
All tests pass, and there are no leaks in the new code. It's just a
NEWS blurb away from being just another hectic release memory :-)
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
On 7/8/06, Tim Peters [EMAIL PROTECTED] wrote:
Back in:http://mail.python.org/pipermail/python-dev/2005-March/051856.htmlI made a pitch for adding:sys._current_frames()
to 2.5, which would return a dict mapping each thread's id to thatthread's current (Python) frame.As noted there, an extension
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
18 matches
Mail list logo
