English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
type inference for python
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2005-02-01 (23:06)
From: Philippe Fremy <pfremy@i...>
Subject: Re: [Caml-list] type inference for python

	Hi Skaller,

Thank you for your very detailed explanation. You have obviously 
dedicated a lot of thought to the problem. I know understand that it is 
indeed necessary to almost rerun the interpreter to check the code. 
Actually, that's what pychecker does.

But even running the interprter would probably not be enough. I knew 
when asking that the problem was probably beyound my reach. Now, I know 
why :-).

> Sure, but what do you mean 'trick Python'? Writing code
> based on the specified semantics -- including exception handling --
> is not a trick.

Actually, I realise that there are many usage patterns for python. Some 
people like you use it for its highly dynamic nature. I use it mainly as 
an easy Java/C++ replacement and it would be ok for me to drop many of 
the dynamic aspect, in order to get more type and execution safety.

> Unfortunately, 'most code' is easily type checked by a
> single test case. 

Well, it is so easy to make a small mistake with big consequences. An 
intern just wrote some code for me where he was supposed to return a 
list. In one case, he would return a None instead of an empty list, and 
broke the program the whole concept (always review the code written by 
intenrs :-).

There should be a way to avoid that kind of silly mistakes.

> you might consider establishing a protocol for type annotations 

This is already being discussed in python-dev by more advanced 
programmer than I am. And raises a lot of controversy on how to do it 
and whether it will be useful.

Anyway, discussing the topic gave me a higher view of the problem. 
Python is currently a single solution (CPython) that lends itself to 
many programming paradigm, but in an unsatisfactory manners for some of 

I would like to get rid of the dynamically nature of the language 
sometimes, which some people consider equivalent to killing it. That's 
how I would react if somebody suggested to "remove all the OO crap of 
python" and use it like a good pascal replacement. Still, it would be a 
valid use.

The good news is that a solution is coming for this problem: pypy. This 
generated implementation of python should allows to build python 
interpreter with different feature set. They also have a nice program 
flow chart where they can infer types and optimise code to a wild level.

So, I just have to find myself another fun project :-). Thank you for 
your answers.



Philippe Fremy
InSeal Technical Director
tel: +33 6 07 98 76 44