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

[skaller]

Jeremy Hylton wrote:

> Here's a variation that I have been thinking about; not sure if it
> makes sense.  Instead of having types that correspond to sequence,
> mapping, etc. use a set of micro-types that apply to specific API
> calls.  So a type might have __getitem__ and __len__.  It's not
> unusual to have a user-defined class that only implements a few of the
> methods you'd expect a sequence to have.

	This suggestion makes sense at one level: what you describe
seems close to 'signature matching', which is the basis of 
structure typing in some languages.

	One problem I have with this, is that the optimisations
that I perceive don't come from such high level dynamic
safety checks on user defined classes, but on knowing
that something is an 'int' so I can generate code that
doesn't do any dynamic lookup of an __add__ method,
but just generates the equiavelant of, say

	x = y + 42;

in C. So it is actually the basic types like int,
float, string, list, tuple, that need typing
most, from an optimisation perspective: at best,
requiring an object have an '__len__' method
would allow it to be cached (lookedup once),
but it still has to be called .. by interpreting
some python code. This is so expensive anyhow,
that the caching is probably irrelevant.
But maybe not -- if the method itself is compiled.
Hmmm.

-- 
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