[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> Mark.