[Python-Dev] Catching "return" and "return expr" at compile time
Fri, 10 Sep 1999 17:36:39 +1000
[Tim laments the death of lint for C :-]
> The notion that a valuable idea will never get into the core
> is disturbing.
Agreed. I based my assesment simply on my perception of what is likely to
happen, not my opinion of what _should_ happen. I do agree that it is far
far preferable for Python itself to be capable of issuing these warnings,
and if Guido feels that is the best direction then it would be very cool.
Only Guido can state if he would support such efforts, and probably should
right about now (the funk soul brother - sorry - just got the Fat Boy Slim
CD, and its going around in my head :-)
> 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.
Which tends to be the biggest problem with it. A number of people have
tried to use it, but often get stymied by the lack of 1.5.?isms - ie,
"raise" (ie re-raise) and "assert". It bombs at these statements, and
there is some real magic I didnt want to understand. Aaron agrees that a
parser module based one would be better.
But your original point still remains - I agree having Python do this is a
better solution all round.
> (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.
Agreed. However, all of these would be very valuable and account for the
vast majority of my errors.
> you-windows-guys-write-strange-code<wink>-ly y'rs - tim
Only cos we use a strange OS <wink>