Re: [Caml-list] type inference for python

[Philippe Fremy <pfremy@inseal.com>]

	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