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

Guido van Rossum guido@CNRI.Reston.VA.US
Fri, 10 Sep 1999 10:05:23 -0400


> 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 :-)

I agree it should happen, and Tim's argument about keeping lint and
compiler together is a convincing one.

What stands in the way?

(a) There's so much else to do...

(b) *Someone* needs to design a good framework for spitting out
warnings, and for giving the programmer a way to control which
warnings to ignore. I've seen plenty of good suggestions here; now
somebody should simply go off and come up with a proposal too good to
refuse.

(c) I have a different agenda with CP4E -- I think it would be great
if the editor could do syntax checking and beyond *while you type*,
like the spell checker in MS Word.  (I *like* Word's spell checker,
even though I hate the style checker [too stupid], and I gladly put up
with the spell checker's spurious complaints -- it's easy to turn off,
easy to ignore, and it finds lots of good stuff.)

Because the editor has to deal with incomplete and sometimes
ungrammatical things, and because it has to work in real time (staying
out of the way when you're frantically typing, catching up when your
fingers take a rest), it needs a different kind of parser.

But that's another project, and once the Python core has a warning
framework in place, I'm sure we'll find more things that are worth
warning about.

I'm not always in agreement with Tim Peters when he says that Python
is so dynamic that it's impossible to check for certain errors.  It
may be impossible to say *for sure* that something is an error, but
there sure are lots of situations where you're doing something that's
*likely* to be an error.

E.g. if the compiler sees len(1), and there's no local or global
variable named len, it *could* be the case that the user has set up a
parallel universe where the len() built-in accepts an integer
argument, but more likely it's an honest mistake, and I would like to
get a warning about it.

The hard part here is to issue this warning for len(x) where x is some
variable or expression that is likely to have a non-sequence value
(barring alternate universes); this might require global analysis
that's hard or expensive enough that we can't put it in the core
(yet).  This may be seen as an argument for a separate lint...

--Guido van Rossum (home page: http://www.python.org/~guido/)