Scoping "bug" ?
Kevin Bailey
noone at nowhere.com
Tue Aug 22 00:59:47 EDT 2000
Alex Martelli wrote:
>
> As long as you don't mind getting such warnings when they're
> not really warranted
huh ? There was a line of code in my example that, when run,
halts the Python interpretter. I'd like to know about such
lines.
> , with no good way to turn them off except
> by inserting otherwise-useless bindings,
I guess I've misunderstood something. It seemed to me that
you supported the 'global' directive (which is necessary
to fix my example.) The alternative is the way I
assumed it worked - variable assignment is definition.
> 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.
It was worthwhile enough for Gnu C/C++. I find it handy, as
you implied, not for my own code but, you know, for beginners.
If Guido has his way, "everyone" will be programming in Python.
I think it would be useful to them.
> A key design choice of Python is to compile *very, very fast*,
If this is even true, it is a bad choice. Make your .pyc's
and move on. I might be able to believe decisions to speed
execution but compiling ? Nope.
> How many of
> your errors are intended uses of global variables where you
> forgot the 'global x' declaration? For me, surely less than 1%
Fine. What about code where it's possible to use a _local_
variable without binding it ?
> I would not approve of a 1%
> slowdown of compilation to diagnose these specific errors
1% is 1% no matter how many test cases you have. You would
notice an extra minute on a 2 hour test ?
Now compare this to the time it would take all those beginners
to find the source of an error like this.
> Maybe, a separate lint-like utility would be a better approach:
The existence of lint didn't help the decision to keep "uninitialized
variable" warnings out of gcc.
I really think the frustration of the many outweighs the
inconvenience of the few.
More information about the Python-list
mailing list