[Python-Dev] Catching "return" and "return expr" at compile time

Tim Peters tim_one@email.msn.com
Fri, 10 Sep 1999 02:16:20 -0400

[Mark Hammond]
> ...
> On my third hand, I would _really_ like to see this in a lint tool
> rather than in the core.  I realize there is no such tool at the
> moment, but IMO is where we should be heading.

Following the lead taken by other modern languages, like javalint, c++lint,
perllint, dylanlint and even vblint <wink>?  C lint was a hack needed due to
the combination of bad language design choices and poor compilers, but C
compilers are smarter now than lint ever was.  Who still uses lint?  It's
dead, and it's not missed.

> Skip's return statement warnings are fine and a nice addition, but in
> my experience account for a trivial number of my errors.  Stuff like
> warning about a variable name used only once, for example, will probably
> never get into core Python but in my opinion is far more valuable.

The notion that a valuable idea will never get into the core is disturbing.
I don't really care how it's implemented, but a *visibly* separate
"checking" tool is bad UI, one that even the C community left behind with

> So adding this "-w" switch is fine, but still doesnt give us the framework
> we need to actually create a truly useful package of warnings for the
> Python developer.

No, but adding the "-W" <wink> switch does give us the means by which
(perhaps the illusion of) "a" smarter compiler can be invoked & controlled.

> [And I am slowly and painfully starting work in this - a lint tool based
> on the Python parser module.  Dont hold your breath though :-]

Aaron W has had a capable pylint tool for a couple years, & it remains
virtually unknown; and, far as I can tell, Aaron reciprocated the lack of
interest by dropping active development.

So why was C lint successful in its day while every crack at pylint flops
(btw, yours will too <0.5 wink>)?  I think it's two sides of the same coin:
C lint found dozens of deadly problems that infested almost all C code
(remember the pre-prototype days?).  Versions of pylint offer very little
beyond pointing out unique vrbl names, perhaps indentation checking, and
...?  I'm drawing a blank here.  I suppose they should strive to give better
msgs for runaway triple-quoted strings.  What else?  Skip's "return"
checker, and far as I can tell then we're already at the point of
diminishing returns.

My claim is that pylints don't get used both because they're a separate
step, and because the odds of them catching something interesting are
comparatively tiny.  Python simply doesn't have many errors that *can* be
caught at compile-time.  It's like me firing up the spell-checker at this
point to verify "compile-time" -- the expected payoff is negative.

There's little enough useful a pylint could do that a mod to add those few
smarts to the core would be a fraction of the size & effort of yet another
separate tool.  Better, in the core, it would actually do people some good
because it would actually get used.

Which specific problems do you expect your lint tool to uncover?  Perhaps
there's a world of mechanically-checkable Python errors I haven't yet bumped

you-windows-guys-write-strange-code<wink>-ly y'rs  - tim