The way to a faster python [was Python IS slow !]

Martijn Faassen faassen at pop.vet.uu.nl
Mon May 10 16:00:27 EDT 1999


Evan Simpson wrote:
> 
> Consider a VM for SPython/Swallow code which is linked to standard CPython.
> S-code can manipulate raw integers, floats, arrays, etc which are statically
> typed due to some kind of declaration, inference, or C interface.  Untyped
> objects are simply normal Python objects, and all operations on them are
> handed off to CPython. 

So you're implying that you can call a Swallow function with Python non
swallowable objects, in which case the equivalent Python code is
executed (instead of the Swallow code?). Or if you're not, it's an
idea.. Swallow is a subset of Python, so why not exploit that in some
way...

[snip good discussion on how to mix Python and Swallow code, and even C
headers...]

> Food for thought: Should "x = int(42)" in S-code create an integer object
> and imply that "x" is dynamic, or should it imply that "x" is an integer
> variable with value 42? 

It depends on the Swallow definition of 'int'. Is 'int' overloaded, so
that instead there are multiple functions that can respond to ints,
strings, etc respectively? Or is there only a single 'int' function?

If types are fully specified (as in my original Swallow idea), 

x would have to be of type int, or it won't compile
42 is a constant, and can be automatically determined to be of type int

So x would be an integer variable with value 42.

If there's some way to declare objects completely dynamic within
Swallow, however, it gets complicated. I'd say this is work after the
basic Swallow thing is working in isolation...
 
> Whichever one you picked, how would you spell the
> other? 

Well, if you have external type declarations, you'd say something like:

__type_x = StaticTypes.int

or 

__type_x = StaticTypes.dynamic 

in the dynamic case...

> How should C declarations be "imported"?  In comments?
> As CPython-ly
> illegal identifiers (eg. quoted strings)?  Would it make sense to define
> S-type namespaces as ordinary CPython extension types?

This whole idea of directly importing C declarations is cool, but it
wasn't in the original plan..

If you allow importing of C declarations you lose the strict subset of
Python however, and the benefit of fast testing. Unless of course you
extend CPython to do the same C declaration importing as well...

Thanks for your insights!

Regards,

Martijn




More information about the Python-list mailing list