Why Python is not both an interpreter and a compiler?

[Jussi Piitulainen]

Steven D'Aprano writes:
> On Wed, 2 Sep 2015 02:20 am, Marko Rauhamaa wrote:
>> Steven D'Aprano:
>> 
>>> I believe that Marko is wrong. It is not so easy to compile Python
>>> to machine language for real machines. That's why the compiler
>>> targets a virtual machine instead.
>> 
>> Somehow Guile manages it even though Scheme is at least as dynamic a
>> language as Python.
>
> It's not about the dynamicism precisely, it's about what counts as
> primitive data types and operations.
>
> What are the primitives in Scheme? In Python, the primitives are
> pretty complex. I don't know how accurate this page is:
>
> https://en.wikibooks.org/wiki/Scheme_Programming/Scheme_Datatypes
>
> but it suggests that Scheme primitives are quite close to the
> machine. That may keep the runtime small.

I think I spotted a tiny inaccuracy, but the real problem with that page
is that it's *very* incomplete: no mention of exact integers and
rationals, strings appear in text but not as an entry, were vectors even
mentioned?, nothing about procedures!, let alone reified continuations,
nothing about input/output ports. Also records (definable types with
named fields) are now officially in for some time already, so that's
another kind of structured types. Many implementations have object
systems, possibly modules as objects.

It's quite analogous to Python's objects.

Eval in Scheme is more restricted. Procedure internals are not
accessible at all, and implementations typically offer ways to declare
that standard names in a compilation unit indeed have their standard
meaning and variables will not be assigned outside the given compilation
unit, so the compiler can propagate information about expected argument
types around, infer more types, inline code, and lot's of things that
are way beyond me.

Some Scheme implementations use quite aggressive compilation techniques.
Guile is one, I think. Gambit and Larceny are two others.

[- -]