[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
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 ough
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 gui
[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
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
>
+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 ess
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 debugging deadlocks.
If you ask for positive
[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
o
On 10/07/06, Alexander Schremmer <[EMAIL PROTECTED]> wrote:
> 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? :-)
>
I'm the SoC stude
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
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 7/9/06, Tim Peters <[EMAIL PROTECTED]> 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 a
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 :-)
[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 pys
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 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.
>
On 09/07/2006, at 9:05 AM, Anthony Baxter wrote:
> I'm really not keen on this seeming tide of new features 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 has
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) fra
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 exte
> 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 cu
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 e
20 matches
Mail list logo