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

[Christian Tismer]

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.  You can mix & match equivalent types by
> automatically casting them static or dynamic.  Anything imported from a *.py
> module is dynamic, anything from a *.spy is static.  Probably CPython code
> could only import (auto-wrapped) classes, instances, and functions from
> S-modules.  S-code can import anything from CPython modules, S-modules, or C
> headers (with SWIGgish limitations).  S-namespaces are fixed at creation,
> but if you need to use dynamic objects in some S-code, simply import them
> from a helper module written in CPython.

Huh? How do you import into a fixed-at-creation namespace.
What do you mean by casting into static or dynamic.
Isn't that exactly what I pointed out: Everything must be turned
into something different.

So neiher is a subset of the other.

> 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?  Whichever one you picked, how would you spell the
> other?  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?

I have the impression that it should work this way.
An S-type should be from a special, imported CPython module
with the property of S-ness. Everything must be coerced
from dynamic to static to make this coexist.
This seems to be the easist for me to imagine.
S-Python must not be able to use CPython's objects freely
with a different semantic, or we will get into trouble
with threading.
This is already the case with objects shared the wron way,
but would give you just a traceback.
If S-Python is really efficient, it would give a core dump.

C-Python must pack things up into S-Python world and back.
S-Python may reach out, but this always forces it to use
coercions to local copies.

Could be a little much to implement.
I fear we must throw a lot away, or we get a different language
instead of an embedded tool.

If we just forget about classes and modules, and just think
of some basic S-objects for S-functions?
Strings already carry S-ness. Lists don't, but the arraymodule
has it. Tuples must once be checked for their elements type,
and if they are all the same and not mutable, the work.
Lists could be handled similar, but only if there is no other
reference to them, meaning to pass a copy, or loose all
outer references by that.

So far if we don't want to write new types,
and that's what I'd start to play with.

ciao - chris

[well I'm so tired that S_Python might become as 
 empty as my brain, so better another day :-]

-- 
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