From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 5E325BC88 for ; Tue, 1 Feb 2005 11:54:21 +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 j11AsK7G001924 for ; Tue, 1 Feb 2005 11:54:21 +0100 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id LAA01175 for ; Tue, 1 Feb 2005 11:54:20 +0100 (MET) Received: from postfix4-1.free.fr (postfix4-1.free.fr [213.228.0.62]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j11AsI5X001915 for ; Tue, 1 Feb 2005 11:54:20 +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 D50D328BBFE for ; Tue, 1 Feb 2005 11:54:17 +0100 (CET) Message-ID: <41FF5FD6.5050008@inseal.com> Date: Tue, 01 Feb 2005 11:54:14 +0100 From: Philippe Fremy User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: caml-list Subject: Re: [Caml-list] type inference for python References: <41FF1305.30308@inseal.com> <1107241087.23973.242.camel@pelican.wigram> In-Reply-To: <1107241087.23973.242.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 41FF5FDD.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 41FF5FDA.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 inference:01 inference:01 def:01 def:01 pointers:01 iterating:01 beginners:01 exception:01 exception:01 polymorphic:01 idiom:01 assertions:01 typing:01 exceptions:01 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, > I do. I did considerable work on this. The project > was called Vyper. Woa, Vyper looks like a killer project. But unlike vyper, my goal is not to provide an alternative python implementation with type inference and other goodies. I aim at something like pychecker. That is, a tool that you can run to check the types consistency of a python. It is perfectly acceptable for it to be limited and to report false warning for twisted constructs. The goal is just to make python programming more friendly. There are many small mistakes that could be caught by such a tool and creep in python programs. I keep thinking about the interview of a mailman developer, who said that a big problem of python is that eventhough you have a program running for a long time, there might be some hidden place where you did type mistake that will break your whole program with an exception. Regarding this, python is no better than C program segfaulting. > (3) Python specs weren't written by someone knowing about > languages and standardisation. By far the worst problem > was exceptions. It is tricky for sure. >>1. analyse all the constraints of the code >>Ex: >>def f(a): a.append(1) >>def g(a): a=a+1; f(a) >>g('coucou') >> >>=> a must support append > > > No, you cannot assume that due to the 'exception' problem > mentioned above. Indeed, the append could be a problem if it is meant to be caught by an AttributeError exception. This is why I never liked exceptions. When deeply hidden, they break the execution flow too much and are just as dangerous as pointers. But since I am taking the "helper tool" approach, it is ok to make assumptions that will trigger real warning in 90% of the cases and false warning when you trick python too much. You can then disable the warning in your code, like pychecker does. I am ready to make a few assumptions as a starter: - operations on int/float will return an int or float - operation + involves two objects of the same type and return an object of the same type - AttributesError are not supposed to be raised and add whatever other simplification is necessary in order to get a limited but useful tool. > Alternatively, it could be anything, > and the called of g() is again relying on a type error > to throw an exception. Did you find a lot of code relying on this idiom ? That's clearly a stopper, but I am ok for ignoring it. It would be probably ok to detect this if the try/catch is in the same block. If it is not in the same scope, I consider this bad programming practice anyway so I do not mind throwing a warning. > >>2. cross-validate the constraints consistency >>=> inconsistent assertions > > > Python variables are all polymorphic. It isn't > inconsistent to have > > a is an int > a is a string > > This is possible, at different times .. as an example: > > for i in [1,"string"]: .. > > i is first an int then a string. Sure. I used to program a bit like that: def f(a): if not type(a) is type([]): a = [a] That means that the type of a variable must be tied to a portion of the code or would have to be one of a possible choice. Iterating over lists with variable types is sure tricky. But again, that's not a common programming pattern (or is it my imagination). You had the constraint of supporting every language feature. I can afford to support only 50% of them. That would already be a big win over the current situation. I understand that python typing is so loose that it creates many problems. I am puzzled because the industry uses poor languages to do important things. Our life depends so much on computers those days that it is a pity to uses such insecure languages. There have been a lot of good languages produced but few of them really caught on. Whay I like in python is that it has some characteristics that make it an easy to pick language, and it can replace C++, VB and Java in many areas. But this type fully dynamic types is one of its strength but also the number one error made by beginners. regards, Philippe -- Philippe Fremy InSeal Technical Director tel: +33 6 07 98 76 44