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

[Christian Tismer]

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! :-)

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

...

> > No, I meant functions as first class objects. Would you bind
> > them statically, so they never change?
> 
> I thought I was talking about this too (but in C terms).
> 
> A function would get a static type, which is the type of its arguments
> (and the amount of its arguments). The type of what it returns can be
> included too (though we can get overloading problems that way so this
> needs more thinking).

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?

...
> > Interpreting everything is as wrong as compiling everything.
> 
> That's why we keep Python proper, right?

Of course. 90% of Python is fine, 5% would need to be very
fast. (making 95%, sorry, this was an unforeseen input
to my swallowed brain.py :-)

...

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

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

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.

a=b=c(a)[b].x=len(globals()) - ly y'rs chris

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