Without an implementation and supporting profile data nobody is going
to believe that you can do name lookup faster than with the built-in
dict type in CPython. Note that names seen by the parser are already
interned, so most of what you seem to be proposing is already
implemented...
On Wed, Mar
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 unique
* Neal Norwitz [EMAIL PROTECTED] [2008-03-18 18:54:47 -0500]:
First, you should measure the current speed difference. Something like:
$ ./python.exe -m timeit -s 'd = {1: None}' 'd[1]'
100 loops, best of 3: 0.793 usec per loop
$ ./python.exe -m timeit -s 'd = {1: None}' 'd[1]'
100
It appears to me that if you can make mapping mechanisms faster in
Python you can make significant
overall speed improvements. I also think the proposed concept could
add flexibility to persistence formats
and RMI interfaces.
My basic idea is to have a constant string type with an interpreter
On Wed, Mar 5, 2008 at 4:27 PM, Henrik Vendelbo [EMAIL PROTECTED] wrote:
It appears to me that if you can make mapping mechanisms faster in
Python you can make significant
overall speed improvements. I also think the proposed concept could
add flexibility to persistence formats
and RMI
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 unique integer idea.
If the
