Scoping "bug" ?

Alex Martelli alex at magenta.com
Mon Aug 21 18:09:15 EDT 2000


"Kevin Bailey" <noone at nowhere.com> wrote in message
news:39A18EDD.33C70A2C at nowhere.com...
> Alex Martelli wrote:
> >
> > The determination of what namespace[s] to look up a binding in
> > is done at compile-time.  The actual look up is done at run-time.
>
> Fair enough. Then the "compiler" should be more than capable of
> giving a warning that the variable may be used before being
> bound.

As long as you don't mind getting such warnings when they're
not really warranted, with no good way to turn them off except
by inserting otherwise-useless bindings, I think it could be
arranged. Otherwise, you'd need to add basic-block analysis
to the Python compiler, which currently has no other need for
it.  The trade-off does not seem particularly worthwhile to me.

A key design choice of Python is to compile *very, very fast*,
rather than spend more time in compilation to provide compile
time diagnosis of errors rather than runtime.  How many of
your errors are intended uses of global variables where you
forgot the 'global x' declaration?  For me, surely less than 1%
(I eschew global variables whenever I can, and I make plenty
of errors of _other_ kinds:-).  I would not approve of a 1%
slowdown of compilation to diagnose these specific errors, as
it would hurt my turnaround time on the extremely numerous
and pervasive tests that I put in place to diagnose all of the
other errors anyway.  Even if 'compile carefully for diagnostic
purposes' was a switchable option, I suspect that just enlarging
the working set for the compiler might slow it down by this
much.

Maybe, a separate lint-like utility would be a better approach:
keep the compiler fast, run a separate check whenever you
think it's warranted.  There are several 'Python lint' thingies
around -- not sure any of them does specifically what you
want, but, why not give them a try...


Alex






More information about the Python-list mailing list