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
Brett Cannon wrote:
> On 7/7/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> On 7/8/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
>> > I'd like the answer to be yes. It sounded for a while like this
>> > was not part of Brett's plan, though. Now i'm not so sure. It
>> > sounds like you're also i
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
On 7/7/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
On 7/8/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:> The situation you're describing here is a classic case of one> component keeping a closely held authority while using it to
> provide some limited capability to some other component. This> com
On 7/7/06, Talin <[EMAIL PROTECTED]> wrote:
Brett Cannon wrote:> On 7/7/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:> On 7/7/06, Brett Cannon <[EMAIL PROTECTED]
> wrote:>> > I guess I am just not seeing where your approach is better than>> preventing>> > the constructor in 'file' and having
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
> i thought avoiding a second dict lookup should be faster, but it turned out
> to be completely wrong.
Unless you have an expensive hash function, it is almost never worth it to try
to avoid a second lookup. Because of memory cache effects, the second lookup
is
dirt cheap (a cache miss is abo
tomer filiba wrote:
> i thought avoiding a second dict lookup should be faster, but it turned out
> to be completely wrong. it's only marginally faster, but if an exception
> occurs, it's x10 slower.
maybe you should take this to comp.lang.python instead...
___
i thought avoiding a second dict lookup should be faster, but it turned out to be completely wrong. it's only marginally faster, but if an exception occurs,it's x10 slower.## the code#>>> import time
>>> b = dict((i, 7) for i in range(1000))
>>> def try_lookup(k):... try:... return b[k]
10 matches
Mail list logo
