Neil Toronto wrote:
> As long as patches are flying willy-nilly and we're just kicking around
> ideas like puppies, I thought I'd offer one of my own.
>
> No, not a puppy. An idea. Of course, if it ends up beaten to death, I
> might rather it were a puppy. My apologies if it's been discussed in
> some other form.
>
> It occurs to me that some of Python's gotchas are due to the compiler
> not being able to determine whether the user intends to *create* a
> variable, or *modify* one.
Any proposal such as this also needs to addresses all of the *other* name
binding statements in Python:
try/except
for loop
with statement
def statement
class statement
All of these statements bind a name in the current scope regardless of whether
or not that name is used elsewhere in the current scope or an outer scope.
The current behaviour of assignment statements is identical - they all bind a
name in the current scope (with augmented assignment statement expecting that
the name already be defined).
This proposal introduces a *new* statement (var) to take on the meaning of the
current assignment statement, and proposes to give assignment statements a
special "rebind" behaviour that will silently break code like the following
due to the missing 'var' on the inner x variable:
for x in range(10):
def some_op(y):
x = y+2
real_op(x, y)
for y in range(x):
some_op(x, y)
I prefer my non-local effects to be explicit, thank-you-very-much. A solid -1
here.
Regards,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
