Neil Toronto <[EMAIL PROTECTED]> writes:
> For the record, though I didn't present it this way in my initial
> proposal, I like #1 and #2 better than #3. Otherwise, you'd get this
> silliness:
>
> def f():
> x = 3 # fine, because the magic 'var' down below creates it
> var x = 0
In my semantics #3 this would be a runtime error at the assignment
(the compiler could catch it statically in this case, but not always).
Neil Toronto <[EMAIL PROTECTED]> writes:
> var x = 0
> def f():
> if sometest:
> var x = 3
>
> x = 2
>
> which is seriously evil, because it's not clear which 'x' the last
> assignment refers to.
Should be:
var x = 0
def f():
var x
if sometest:
x = 3
x = 2
For 'for' loops there are two choices:
1. 'for x in coll' creates x which is local to the loop.
2. 'for var x in coll' creates a local x, 'for x in coll'
modifies an existing x.
I admit that Python choices of expressing certain constructs
(conditionals, loops) as statements instead of expressions
make a sane semantics of variable declarations less convenient.
--
__("< Marcin Kowalczyk
\__/ [EMAIL PROTECTED]
^^ http://qrnik.knm.org.pl/~qrczak/
_______________________________________________
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
