Why not a Python compiler?

[Paul Boddie]

On 8 Feb, 08:16, Arnaud Delobelle <arno... at googlemail.com> wrote:
>
> [snip more interesting considerations about compiling python]
>
> Please get back on topic.  This discussion is about parsecs and
> wookies now.

Yes, it's like the lower-value parts of Wikipedia have spilled out
onto Usenet. ;-)

But I think Hrvoje's post summarises quite well: Python operations are
not directly equivalent to the primitive operations which often employ
the same symbols (eg. arithmetic operators), determining the
attributes of objects typically requires relatively expensive
operations (compared to optimised cases in other languages),
predicting the outcome of such run-time operations is difficult
because even the slightest change can have global consequences.

That said, there are some things in Python which are intentionally
predictable: names are always associated with a particular scope
(local, global), access to such scopes is not configurable (unlike
access to instance namespaces, for example). Moreover, people have
asserted that many programs do not use the full potential of Python's
dynamic facilities. For example, how many programs do something like
this...?

  class A:
    ...

  class B:
    ...

  for cls in A, B:
    class C(cls):
      ...

Removing the mere possibility of such stuff piece by piece, or rather
telling the programmer that it makes their programs run slow, could
make Python programs more readily inspectable and potentially more
open to optimisation. I regard this as a more interesting route than
just slapping type annotations all over the place and pretending that
Java's younger brother hasn't just been conceived.

Paul