From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 0E73CBC88 for ; Wed, 2 Feb 2005 00:06:41 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j11N6eNS010923 for ; Wed, 2 Feb 2005 00:06:40 +0100 Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id AAA04601 for ; Wed, 2 Feb 2005 00:06:40 +0100 (MET) Received: from postfix4-1.free.fr (postfix4-1.free.fr [213.228.0.62]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j11N6du2000941 for ; Wed, 2 Feb 2005 00:06:39 +0100 Received: from [192.168.1.101] (marcadet-4-81-56-68-124.fbx.proxad.net [81.56.68.124]) by postfix4-1.free.fr (Postfix) with ESMTP id 7C6F228C108 for ; Wed, 2 Feb 2005 00:06:39 +0100 (CET) Message-ID: <42000B7B.5000204@inseal.com> Date: Wed, 02 Feb 2005 00:06:35 +0100 From: Philippe Fremy User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 Cc: caml-list Subject: Re: [Caml-list] type inference for python References: <41FF1305.30308@inseal.com> <1107241087.23973.242.camel@pelican.wigram> <41FF5FD6.5050008@inseal.com> <1107261444.23973.324.camel@pelican.wigram> In-Reply-To: <1107261444.23973.324.camel@pelican.wigram> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 42000B80.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 42000B7F.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 inference:01 semantics:01 intern:01 wrote:01 annotations:01 lends:01 optimise:01 exception:01 dynamically:01 patterns:02 python:02 python:02 types:02 programming:03 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.2 X-Spam-Level: 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 them. 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. regards, Philippe -- Philippe Fremy InSeal Technical Director tel: +33 6 07 98 76 44