Shed Skin Python-to-C++ Compiler 0.0.21, Help needed

[Paul Boddie]

On 2 Apr, 09:17, John Nagle <n... at animats.com> wrote:
>
>      Something else worth trying: type inference for separately
> compiled modules using the test cases for the modules.

I mentioned such possibilities once upon a time:

http://blog.amber.org/2004/12/23/static-typing-and-python/

Note the subject of the original article, by the way. And as a
postscript, I'd advise anyone wondering what happened to Starkiller to
take a look at Shed Skin instead, since it more or less does what
Starkiller was supposed to do.

>  One big problem with compile-time type inference is what to do
> about separate compilation, where you have to make decisions
> without seeing the whole program.  An answer to this is to
> optimize for the module's test cases.  If the test cases
> always use an integer value for a parameter, generate hard
> code for the case where that variable is a integer.  As long
> as there's some way to back down, at link time, to a more general
> but slower version, programs will still run.  If the test
> cases reflect normal use cases for the module, this should
> lead to generation of reasonable library module code cases.

People are always going to argue that a just-in-time compiler saves
everyone from thinking too hard about these issues, but I still think
that there's a lot of mileage in deducing types at compile time for a
number of reasons. Firstly, there are some applications where it might
be desirable to avoid the overhead of a just-in-time compilation
framework - I can imagine that this is highly desirable when
developing software for embedded systems. Then, there are applications
where one wants to know more about the behaviour of the code, perhaps
for documentation purposes or to help with system refactoring, perhaps
to minimise the risk of foreseeable errors. Certainly, if this latter
area were not of interest, there wouldn't be tools like pylint.

Paul

P.S. Another aspect of the referenced article that is worth noting is
the author's frustration with the state of the standard library:
something which almost always gets mentioned in people's pet Python
hates, but something mostly ignored in the wider enthusiasm for
tidying up the language.