Re: [Python-Dev] A thought on generic functions

Greg Ewing wrote: Paul Moore wrote: I'd rather see a solution which addressed the wider visitor use case (I think I just sprained my back bending over backwards to avoid mentioning generic functions :-)) Speaking of generic functions, while thinking about the recent discussion on proxy objects

Re: [Python-Dev] Python 3000: Special type for object attributes & map keys

Greg Ewing wrote: > Neal Norwitz wrote: >> Part of this is done, but very differently in that all strings used in >> code objects are interned (stored in a dictionary > > And since two interned strings can be compared > by pointer identity, I don't see how this differs > significantly from the "un

Re: [Python-Dev] PEP: Lazy module imports and post import hook

Aside: Nick Coghlan wrote: > My main concern is that the import lock is something Python users > typically don't have to worry about (aside from the 'don't spawn a > thread as a side effect of importing' guideline)... I've never heard of this and I can't get Google to find it. Is it a deadlock

Re: [Python-Dev] PATCH: attribute lookup caching for 2.6

Kevin Jacobs <[EMAIL PROTECTED]> wrote: > On Dec 6, 2007 1:35 AM, Neil Toronto <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > So I've applied Armin's patch to 2.6 (it was nearly clean) and am > playing with it. cls.name <http://

Re: [Python-Dev] PATCH: attribute lookup caching for 2.6

Phillip J. Eby wrote: > At 07:43 PM 12/5/2007 -0700, Neil Toronto wrote: >> FWIW, I like it. Though the hash should really incorporate the hash of >> the type name as well as the attribute's so that sometype.method calling >> othertype.method doesn't invalidate the c

Re: [Python-Dev] PATCH: attribute lookup caching for 2.6

Phillip J. Eby wrote: > At 10:48 PM 12/5/2007 +0100, Georg Brandl wrote: >> Neil Toronto schrieb: >>> So Jim and PJE finally convinced me to do it the right way. :) Thanks >>> guys - it turned out very nice. >> How does this relate to Armin Rigo's method cach

[Python-Dev] PATCH: attribute lookup caching for 2.6

So Jim and PJE finally convinced me to do it the right way. :) Thanks guys - it turned out very nice. http://bugs.python.org/issue1560 http://spreadsheets.google.com/ccc?key=pHIJrYc_pnIUpTm6QSG2gZg&hl=en_US It caches type/metatype attribute lookups, including missing attributes. Summary of the

Re: [Python-Dev] Non-string keys in namespace dicts

Phillip J. Eby wrote: > At 10:17 PM 12/3/2007 -0700, Neil Toronto wrote: >> Interesting. But I'm going to have to say it probably wouldn't work as >> well, since C code can and does alter tp_dict directly. Those places in >> the core would have to be altered t

Re: [Python-Dev] Non-string keys in namespace dicts

Phillip J. Eby wrote: > At 03:51 PM 12/3/2007 -0800, Guido van Rossum wrote: >> On Dec 3, 2007 3:48 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote: >> > Actually, you're missing the part where such evil code *can't* muck >> > things up for class dictionaries. Type dicts aren't reachable via >> > ord

Re: [Python-Dev] Non-string keys in namespace dicts

I apologize - I had forgotten what you were telling me by the time I replied. Here's a better answer. > Phillip J. Eby wrote: >> At 03:26 PM 12/3/2007 -0700, Neil Toronto wrote: >> Actually, you're missing the part where such evil code *can't* muck >> thi

Re: [Python-Dev] Non-string keys in namespace dicts

Phillip J. Eby wrote: > At 03:26 PM 12/3/2007 -0700, Neil Toronto wrote: >> Phillip J. Eby wrote: >> > At 12:27 PM 12/3/2007 -0700, Neil Toronto wrote: >> Some version of the non-string keys problem would exist with any caching >> mechanism, though. An evil rich c

Re: [Python-Dev] Non-string keys in namespace dicts

Phillip J. Eby wrote: > At 12:27 PM 12/3/2007 -0700, Neil Toronto wrote: >> Guido van Rossum wrote: >> > How about subclasses of str? These have all the same issues... >> >> Yeah. I ended up having it, per class, permanently revert to uncached >> lookups when

Re: [Python-Dev] Non-string keys in namespace dicts

Guido van Rossum wrote: > On Dec 2, 2007 12:49 PM, Neil Toronto <[EMAIL PROTECTED]> wrote: >> It turned out not *that* hard to code around for attribute caching, and >> the extra cruft only gets invoked on a cache miss. The biggest problem >> isn't speed - it's

Re: [Python-Dev] Non-string keys in namespace dicts

Nicko van Someren wrote: > On 2 Dec 2007, at 03:09, Neil Toronto wrote: > >> Are there any use-cases for allowing namespace dicts (such as globals, >> builtins and classes) to have non-string keys? I'm asking because I'm >> planning on accelerating method look

[Python-Dev] Non-string keys in namespace dicts

Are there any use-cases for allowing namespace dicts (such as globals, builtins and classes) to have non-string keys? I'm asking because I'm planning on accelerating method lookups next, and the possibility of a key compare changing the underlying dict could be a major pain. (It was a minor pai

Re: [Python-Dev] [poll] New name for __builtins__

Terry Reedy wrote: > "Greg Ewing" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > | I think the situation with __main__ is different from __builtin__, > > I effectively agreed by not disputing Guido's response ;-) Very cunning. But I was even more cunning, and didn't even *consi

Re: [Python-Dev] -O2 faster than -O3?

Neal Norwitz wrote: > On Nov 30, 2007 7:16 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: >> On Nov 30, 2007 12:02 PM, Neil Toronto <[EMAIL PROTECTED]> wrote: >>> On both of my systems, using -O2 reduces execution time in pystone by 9% >>> and in pybench by 8%

Re: [Python-Dev] [poll] New name for __builtins__

Fred Drake wrote: > On Nov 30, 2007, at 6:05 PM, Guido van Rossum wrote: >> It's almost as if nobody has seen my proposal to leave __builtins__ >> alone and rename the __builtin__ module instead. > > > I suspect that's indistinguishable from everyone being tired of the > discussion, knowing tha

[Python-Dev] -O2 faster than -O3?

On both of my systems, using -O2 reduces execution time in pystone by 9% and in pybench by 8%. It's function inlining: "-O3 -fno-inline-functions" works just as well as "-O2". Removing "-g" has little effect on the result. Systems: - AMD Athlon 64 X2 Dual Core 4600+, 512 KB cache (desktop)

Re: [Python-Dev] PATCH: Fast globals/builtins lookups for 2.6

Steve Holden wrote: > Neil Toronto wrote: >> Speaking of which, here's a question for everybody. I was wondering >> whether 64 bits is necessary. It takes an hour of concerted effort - >> nothing but "module.d = 1; del module.d" for an hour straight - to >

Re: [Python-Dev] PATCH: Fast globals/builtins lookups for 2.6

Guido van Rossum wrote: > Hm. > > On my Linux box, in the trunk: > > Before the patch: > Pystone(1.1) time for 5 passes = 1.16 > This machine benchmarks at 43103.4 pystones/second > > After the patch: > Pystone(1.1) time for 5 passes = 1.14 > This machine benchmarks at 43859.6 pystones/s

Re: [Python-Dev] PATCH: Fast globals/builtins lookups for 2.6

Guido van Rossum wrote: > Cool! Can't wait to get my hands on it. How does it affect pystone? Pystone likes it, according to my tests and Chris's. On his machine, if I'm reading these stones right, it takes about 7% off the run time on average. On mine it takes off 4%. > What happens if the glo

Re: [Python-Dev] [poll] New name for __builtins__

Christian Heimes wrote: > Greg Ewing wrote: >> __uberglobal__ > > Since Python 3.0 supports all unicode chars I vote for __überglobal__. Make it untypeable to most Americans so as to discourage use? If that's what we're going for, I suggest the somewhat more self-documenting and less impossible

[Python-Dev] PATCH: Fast globals/builtins lookups for 2.6

I've posted a patch here: http://bugs.python.org/issue1518 for 2.6a0 that speeds up LOAD_GLOBAL to where it's just barely slower than LOAD_FAST for both globals and builtins. It started life here, in Python-ideas: http://mail.python.org/pipermail/python-ideas/2007-November/001212.html The ide

Re: [Python-Dev] New syntax for 'dynamic' attribute access

Anthony Baxter wrote: > I have to say that I'm not that impressed by either the 1-arg or > 2-arg versions. Someone coming across this syntax for the first > time will not have any hints as to what it means - and worse, it > looks like a syntax error to me. -1 from me. > I'm not sure the "loo

Re: [Python-Dev] New syntax for 'dynamic' attribute access

Ben North wrote: > Hi, > > A few days ago I posted to python-ideas with a suggestion for some new > Python syntax, which would allow easier access to object attributes > where the attribute name is known only at run-time. For example: > > setattr(self, method_name, getattr(self.metadata, method_nam

Re: [Python-Dev] Deletion order when leaving a scope?

Thomas Wouters wrote: > On 1/18/07, *Larry Hastings* <[EMAIL PROTECTED] > > wrote: > > > > I just ran a quickie experiment and determined: when leaving a > scope, variables are deleted FIFO, aka in the same order they were > created. This surprised me; I'd ex

Re: [Python-Dev] LSB: pyc stability

Martin v. Löwis wrote: > Brett Cannon schrieb: > >> Did they say why they wanted to distribute bytecode files? I assume it >> is either for space considerations or they think it will help to protect >> their IP somehow. >> > > It's to protect the IP (i.e. for proprietary software). They a