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

[Martijn Faassen]

Christian Tismer wrote:
> 
> Martijn Faassen wrote:
> >
> > Christian Tismer wrote:
> > >
> > > Martijn Faassen wrote:
> >
> > [snip]
> > [Christian describes problems with statically typed globals interacting
> > with Python]
> >
> > Okay, let's remove globals from Swallow for now, then. :) Or make them
> > inaccessible to Python, perhaps.
> 
> Danger, danger! :-)

Thank you, my faithful robot. Oh, no, that was the Timbot, right?
(obscure lost in space reference :)

> Every other function called by Swallow code would usually
> be from some lgobal name space. This is the trouble, see later.
[snip]

> Here we are.
> 
> My module contains just this:
> 
> import string
> 
> def swallowed_func(str):  # assuming str is a string
>     # do something internal, but then
>     return string.strip(str)
> 
> Now, what can we do about string.strip? It's a global,
> alas it is something from non-swallow world which we don't know.
> Wouldn't this program be already be a rejected one?

You are right, but in my head I was thinking about making a subset of
commonly used modules (or at least functions in them, and later on
classes), and make Swallowed variants. Of course this can get a mess,
but Swallow should use those swallowed modules preferably. Perhaps this
is transparant:

string.strip(str)

Error: The Swallow version of the string module does not support
'strip'.

or perhaps not:

swallow.string.strip(str)

Perhaps the transparant option is best, for the subset reason; any
Swallow code should be Python code (but not vice versa).
 
> > > Would mean to have basic S-type things which are known
> > > to produce nothing else, and build everything from these.
> >
> > Admittedly I'm still vague on all of this, but automatic translation of
> > suitable Python code to Swallow code might look like this:
> >
> > * Determine if the Python code is within the Swallow subset. This should
> > be a simple parsing job. I hope.
> 
> Humm. If it means just expressions and local variables, yes.
> If all other called code is swallowed code, yes.
> With a dictionary of known swallow-compatible builtins,
> you might boostrap a couple of swallowed modules,
> but you will break with the first unforeseen import.
> Ending up in recoding a number of libraries, I fear.

Right, as I describe before. This is fairly inevitable if one wants
Swallow. Of course *Python* has no problem calling Swallow code, so that
the Swallow libraries can eventually replace parts of the C extension
libraries. (yeah, yeah, a maniacal plan! Soon Timbot will come and say
"sorry guys, can't/shouldn't be done, because <brilliant explanation>",
I keep fearing :)
 
> > * If it isn't in the subset, complain and give up.
> >
> > * If it is in the subset, we can assume a lot of things all of a sudden.
> > We do some automagic type inferencing, and then function gets swallowed.
> >
> > The problem is the dynamism kicking in unexpectedly; for instance, it's
> > virtually impossible to determine what types arguments of functions are;
> > it may be something rather dynamic is passed into a function that is
> > Swallow parsable, turning the function into something more dynamic after
> > all. But I don't think we're in a dead end yet; possibilities seem to
> > exist.
> 
> I fear here the dog bites its tail.
> We will finally get to the same Python again.
> If swallow wants to be powerful, I think it should
> be restrictive. Just allow for small, fast functions.
> Make them into new building blocks, which are then used
> by the existing Python.
> Dynamic things should sit upon static things, the same
> way as Python is constructed itself.

Agreed! This was the idea, sorry I didn't express it well and got
muddled in details. :)

> Doing more looks to me as to speed up Python as a whole,
> by dynamically figuring out local optimizations depending
> of the current context. This would be phantastic,
> but is far beyond my scope.

Agreed. Let's keep it simple. So:

Swallow is a subset of Python, plus static typing information in a
dictionary. (or possibly this information is more integrated in the
code, but that would involve preprocessors which makes Swallow<->Python
code interchange more difficult).

Initially the plan is to support Swallow functions. Classes come later.
We will need to support 'built-in type' object semantics however (such
as list.append()) right away, though. To avoid class/type dichotomy in
the future it's good to think this through carefully in advance so that
classes can be added smoothly.

The backend of Swallow is either a fast interpreter, automatically
generated C code, or both can be tried.

Make Swallow varieties of most built-in functions. Then go on to some
modules, such as string.

Then see about classes.

How does this outline of a plan sound?

Regards,

Martijn