Python Type-Inference based LINT.. (

Martijn Faassen m.faassen at
Thu Nov 25 22:11:50 EST 1999

Greg Ewing <greg.ewing at> wrote:
> Martijn Faassen wrote:
>> Note that this doesn't need to be a syntax extension; check out some of
>> my Swallow posting with dejanews for examples of how it could work in
>> current Python.

> I think I'd prefer it if it *were* a syntax extension.
> The suggestions I've seen so far for non-syntax-extending
> type declarations strike me as rather ugly.

Oh, agreed -- it's just that it's potentially easier to whip up something
using basic Python, first. Not that much easier on the scale of things, of

Imagine, for instance, a list of integers. A dictionary with string keys and
values of some class. How do you write that down in a proposed syntax 
extension? It's not hard to whip up something with basic Python lists and

> That's a minor point, though -- the main thing is to
> get some sort of type checker to work! The syntax can
> be thrashed out later.

Agreed completely.

>> I myself would take the Python subset approach
>> (i.e. Swallow) to make sure no runtime dynamics exist that can mess up
>> any type checking. Seems to me the easier approach

> Me, too. Also, I tend to think that explicit type
> declarations are a valuable way for the programmer to
> state the *intent* of the code in a way that both
> humans and compilers can process. In my experience,
> type errors are found sooner and reported in a more
> easily understood way when explicit type declarations
> are used.

> I've tried it both ways when using Haskell-like
> languages, and I find that the error messages I get
> when I don't explicitly declare types tend to be of
> the form

>    Couldn't unify <some-big-hairy-complicated-type-
>    expression> with <some-other-big-hairy-complicated-
>    type-expression-that-looks-vaguely-similar-although-
>    there-must-be-some-subtle-difference-if-only-I-can-
>    find-it>.

> After getting a few of those I quickly learned to
> provide type declarations for ALL my functions...

Sounds like we'd need some way to avoid this type of problem with
any 'optional-type-annotated Python'. Of course the Swallow idea is to
*fully* type annotate everything, and then use this to build fast
extension libraries written in (a subset of) Python. This is just to make
things easier, though -- types would be useful in plain Python as well, 
if they were optional. I think. It's hard to say, actually, because if it
*has* to generate error messages like the kind you mentioned, optional
type annotations may not even be worth it..


History of the 20th Century: WW1, WW2, WW3?
No, WWW -- Could we be going in the right direction?

More information about the Python-list mailing list