[Python-Dev] exception too expensive?

2006-07-08 Thread tomer filiba
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]

Re: [Python-Dev] exception too expensive?

2006-07-08 Thread Fredrik Lundh
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... ___

Re: [Python-Dev] exception too expensive?

2006-07-08 Thread Raymond Hettinger
> 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

[Python-Dev] "Missing" 2.5 feature

2006-07-08 Thread Tim Peters
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

Re: [Python-Dev] In defense of Capabilities [was: doc for new restricted execution design for Python]

2006-07-08 Thread Brett Cannon
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

Re: [Python-Dev] In defense of Capabilities [was: doc for new restricted execution design for Python]

2006-07-08 Thread Brett Cannon
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

Re: [Python-Dev] "Missing" 2.5 feature

2006-07-08 Thread Brett Cannon
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

Re: [Python-Dev] In defense of Capabilities [was: doc for new restricted execution design for Python]

2006-07-08 Thread Talin
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

Re: [Python-Dev] "Missing" 2.5 feature

2006-07-08 Thread Raymond Hettinger
> 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

Re: [Python-Dev] "Missing" 2.5 feature

2006-07-08 Thread Georg Brandl
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