What If Python Replaced Elisp?

[Tim Peters]

[Neel Krishnaswami]
> There are actually a whole lot of optimizations that could be done,
> but aren't, in the current Python interpreter.
>
> For example, in the following code:
>
> import operator
>
> lst = []
> for i in range(100):
>     lst.append(i**2 + i**2)
>
> result = reduce(operator.add, lst)
>
> You can statically infer the type of result, the final size of lst,
> avoid actually allocating a range() object, eliminate the the
> typechecks that make sure that i has a __pow__ method, the bounds
> checks on the range object, do available expressions analysis on the
> i**2 to avoid calculating it twice, and probably a few more
> optimizations that I don't know about.

Actually not, you can't do any of that now!  You currently have no way to
know that, e.g., some *other* module didn't import this one (let's call this
one "neel"), and redirect neel.range and neel.reduce to some arbitrary
functions of its own devious choosing.  Heck, the call to neel.range may
even reach back in and change neel.lst to anything at all before the loop
body is entered.  "i" may end up referring to an object whose __pow__ method
sends email to Afghanistan; etc.

This is why the Types-SIG is so keen to impose restrictions on what modules
can do to each others' namespaces (in the presence of optional static
typing).

> ...
> You don't have to win every game to make it to the championships. :)

you-don't-even-need-to-win-one-but-it-sure-can't-hurt<wink>-ly y'rs  - tim