Python Type-Inference based LINT.. (pylint.py)
m.faassen at vet.uu.nl
Thu Nov 25 22:11:50 EST 1999
Greg Ewing <greg.ewing at compaq.com> 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.
>> 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-
> 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