[Python-Dev] More flexible namespaces.

Christian Tismer tismer at appliedbiometrics.com
Fri Apr 30 18:55:55 CEST 1999


"Andrew M. Kuchling" wrote:
> 
> Christian Tismer writes:
> >Instead, If I can manage to create something like static binding
> >snapshots, then I could resolve many of the lookups and internal
> >method indirections, for time critical applications.
> 
>         The usual assumption is that the lookups are what takes time.
> Now, are we sure of that assumption?  I'd expect the lookup code to be
> like:
> 
> 1) Get hash of name
> 2) Retrieve object from dictionary
> 3) Do something with the object.
...
Right, but when you become more restrictive, you can do
lots, lots more. If I also allow to fix the type of an object,
I can go under the hood of the Python API, so you could
add some points 4) 5) 6) here.
But I shouldn't have talked before I can show something.
And at the time, I don't restrict myself to write clean
code, but try very machine specific things which I
don't believe should go into Python at all.

> I also wonder about the costs of all the Py_BuildValue and
> Py_ParseTuple calls going on under the hood.  A performance
> improvement project would definitely be a good idea for 1.6, and a
> good sub-topic for python-dev.

I wasn't sure, so I first wrote a module which does statistics
on that, and I found a lot of these calls. Some are even 
involved in ceval's code, where things like "(OOOO)" is parsed
all over again and again. Now I think this is ok in most cases.
But in some places these are very bad: If your builtin function
soes so very few work. 
Take len(): This uses ParseTuple, which calls a function to
find out its object, then calls a function to get the object,
then takes the len, and builds the result. But since everything
has a length, checking for no NULL pointer and grabbing the len
produces even shorter code. This applies to many places as well.
But right now, I don't change the core, but build hacky little
extension modules which squeak such things out at runtime.
No big deal yet, but maybe it could pay off to introduce
format strings which make them more suitableto be used
in macro substitutions.

sorry if I was too elaborate, this is so much fun :-)

ciao - chris

-- 
Christian Tismer             :^)   <mailto:tismer at appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101   :    *Starship* http://starship.python.net
10553 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     we're tired of banana software - shipped green, ripens at home




More information about the Python-Dev mailing list