Viper: yet another python implementation

[Tim Peters]

[Bruce Dodson]
> ...
> I also think that a python that has enough knowledge of types to
> perform inlining... well, such a beast is no longer Python, no matter
> how similar the syntax appears.

Simple inlining doesn't require any knowledge of types, and would be
valuable in many programs.  The thing that stops it today is that you just
mever know what a name is bound *to*; e.g.,

def f(i):
    return i

def g(i):
    return i+1

def h(indices):
    sum = SomeType()
    for i in indices:
        sum = sum + f(i) + g(i)
    return sum

For all Python knows, the invocation of f, the invocation of g, the hidden
invocation of indices.__getitem__, and/or the invocation of f(i).__radd__ or
sum.__add__ or (sum + f(i)).__add__ or g(i).__radd__ may reach into the
module globals and change the bindings of "f", "g", or both, to anything at
all, or even to different things on each loop iteration.

This is great when you need it, but is likely of no use to 99.9999% of
runtime Python cycles.  If John freezes the module bindings, the guts of the
loop can be mindlessly transformed into

       sum = sum + i + (i+1)

regardless of types with no change in semantics, a major boost in speed,
and-- if done straightforwardly --a major loss of debugability when an add
raises an exception.

there-ain't-no-free-lunch-but-some-good-meals-are-cheap-ly y'rs  - tim