Python Type-Inference based LINT.. (pylint.py)

[skaller]

David Jeske wrote:

> Does it seem more proper to:
> 
>  I. Do all static checking based on the micro-types, and require
>     the function writer to define the type constraints if they want
>     larger granularity?
> 
>     def sumListElements(a_list):
>       'pylint a_list (SequenceType,)'  ## <- this is the syntax pylint.py
>                                        ## supports currently for type
>                                        ## declarations

	Hmmm. A specialised docstring ..

> 
>  II. Always "upgrade" types to proper-types during static checking.
>      If someone wants to have a fine-grained type which just includes
>      __getitem__ and __len__, then force them to at least declare
>      this as a proper type, like "SimpleSequenceType" and then
>      show the signature as:
> 
>      sumListElements( SimpleSequenceType of AddableType ) -> AddableType

I think it depends on what you want to do. First, in the ISO C++
Standard, the same issue arose for algoithms that didn't need the
full functionality of some iterator kind, but the specification
requires the full kind all the same, because there is no 
compact wording for anything else (and it allows implementors
more freedom).

In functional programming languages, signatures tend to be used.
[I.e. mico types].

In Viper, the issue will arise -- but when we're talking
about calling class methods, the overheads are so large 
optimisation isn't relevant. I'm interested in knowing
whether something is an integer or not, or whether
it is precisely a Tuple or not: if a class emulating
a sequence is used, it's irrelevant because optimisation
is impossible [by type inference] in this case.

OTOH knowing _exactly_ which class is passed
to a function in a particular call is important,
since it allows the method calls to be inlined.

-- 
John Skaller, mailto:skaller at maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia
homepage: http://www.maxtal.com.au/~skaller
voice: 61-2-9660-0850