python improvements (Was: Re: New Language)
neelk at brick.cswv.com
Sat May 13 14:10:14 CEST 2000
Moshe Zadka <moshez at math.huji.ac.il> wrote:
> On 12 May 2000, Neel Krishnaswami wrote:
> > If you can declare that a variable is a machine integer or float, and
> > arrays of the same, you have enough information to get about 80% of
> > the speed benefit that static typing can win you.
> What about array-based member lookup, vs. dict-based? I.e., if we can
> optimize foo.bar to be either a 1) compile-time error or 2) an index to
> the member array, it will speed up quite a lot of code.
I bet this one is really hard, because __init__ methods can contain
arbitrary code; in legal Python code different instances of the same
class can contain different slots. (I've seen this used extensively in
real code, too -- people often write methods that add slots.)
But the related problem of speeding up module name lookups isn't
really a type-system problem, and can be solved independently of the
You could add a "static module" type that forbids mutating the module
bindings dictionary after initialization, and doesn't permit the use
of eval/exec statements in code defined in the module. This would
allow a) fast variable lookups for all variables in a static module,
and b) would allow a host of optimizations to be applied. For example,
knowing all the bindings at compile time will let you know if you can
replace range() with an in-C for loop that doesn't have the heavy
> > Before static typing for speed is tried (with its complicating
> > effects on implementation), I think it's better to go for the
> > factor of 2 improvement that can be won via easy tricks like method
> > caches, variable lookup optimization, and reducing function call
> > overhead. (Look at Squeak Smalltalk for an example.)
> Can you give some kind of reference, beside the Squeak Smalltalk
> source code? How easy are the tricks?
Most are pretty straightforward -- the things you think of first when
you think "How can I speed up Python?" For example, Squeak stores
caches method lookups so that it doesn't have to do nested dictionary
lookups to find a method on each call. I think the reason it hasn't
been done in Python yet is because it needs cycles -- a class needs to
know about its subclasses to tell them when the cache becomes invalid.
> > Note also that it can be hard to declare 'machine integer' as a
> > type, if type-class unification becomes reality and you can
> > subclass Integer.
> Not if we have a type system which will allow you to say "an int,
> and nothing else. Not a subclass". I'm very much in favour of such a
> type-system, but I'm a minority -- this seems an OPT-based target,
> and most type-sig people are ERR people.
You should *definitely* look at Squeak, then. They have defined a
subset of Smalltalk that the image can recognize as translatable into
C, and can optimize the hell out of.
More information about the Python-list