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