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

[Evan Simpson]

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.

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?

Christian Tismer wrote in message
<3736B15E.F93811BE at appliedbiometrics.com>...

I still have the problem of "subset".
Python has dynamic namespaces.
Swallow cannot, as far as I see it.
Let's assume that swallow has a known function to import
something, and we assume that import behaves like one would
expect (although that too cannot be guaranteed).
Whenever Swallow imports, it must rely on that the imported
code is swallowable. Since there are a number of dependencies
between the standard module, a single non-swallowable
module would break this rule.
This would mean that finally, Swallow can only rely on
builtin objects which are of quite fixed semantics.

Conclusion: Swallow must redefine almost all modules to
guarantee the assumed semantics, or it has to stay with
primitive types and has to avoid almost all imports.

Now, the subset is getting quite small, since Swallow
may only import swallowed code or builtins. Existing
modules must be swallowed by hand, or be proven to
allways work the same, whenever type resolution and
binding occours.

The other way round: Can python always import Swallow
modules? Only if Python's types behave as Swallow
expects. I fear this doesn't work with global
objects, or we get contradictions. The interface
can only be by some immutability and local copies,
no sharing of mutable objects is possible.

Maybe that I'm looking too much for problems?