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 t
- Original Message -
From: "Neil Toronto" <[EMAIL PROTECTED]>
To:
Sent: Monday, October 09, 2006 6:04 PM
Subject: [Python-3000] Sky pie: a "var" keyword
> 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.
>
Neil Toronto <[EMAIL PROTECTED]> writes:
> 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.
I agree. I've always known this.
I'm only afraid that some people are too accustome
Neil Toronto wrote:
> A "var" keyword fixes them all. The "global" gotcha:
>
> x = 0
> def f():
>print x # no exception - prints "0"
>x = 3
>
> def g():
>print x # exception
>var x = 3
what are the exact semantics of "var" ? are you saying that local variables
should be globa
Fredrik Lundh wrote:
> Neil Toronto wrote:
>
>> A "var" keyword fixes them all. The "global" gotcha:
>>
>> x = 0
>> def f():
>>print x # no exception - prints "0"
>>x = 3
>>
>> def g():
>>print x # exception
>>var x = 3
>
> what are the exact semantics of "var" ? are you sayi
"Neil Toronto" <[EMAIL PROTECTED]> wrote:
> 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.
Yes, but there may not be any solution. One of python's greatest
strengths is the la
"Jim Jewett" <[EMAIL PROTECTED]> writes:
>> A "var" keyword fixes them all. The "global" gotcha:
>
>> x = 0
>> def f():
>>print x # no exception - prints "0"
>>x = 3
>
> But which of the above would this mean?
It should be:
var x = 0
def f():
print x
x = 3
for the global variabl
On 10/9/06, Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> wrote:
> There are a few sane choices for the semantics of 'var':
>
> 1. The variable is visible from 'var' to the end of the scope.
>If 'var' doesn't specify an initial value, accessing the variable
>before it gets assigned to is an
"Paul Moore" <[EMAIL PROTECTED]> writes:
>> 1. The variable is visible from 'var' to the end of the scope.
>>If 'var' doesn't specify an initial value, accessing the variable
>>before it gets assigned to is an error.
>>
>> 2. The variable is visible from 'var' to the end of the scope.
>>
Marcin 'Qrczak' Kowalczyk wrote:
> It should be:
>
> var x = 0
> def f():
>print x
>x = 3
>
> for the global variable, and:
>
> var x = 0
> def f():
>var x
>print x
>x = 3
>
> for the local variable.
so the goal of this exercise is to make it easier to introduce
hard-to-s
Fredrik Lundh wrote:
> Neil Toronto wrote:
>
>
>> A "var" keyword fixes them all. The "global" gotcha:
>>
>> x = 0
>> def f():
>>print x # no exception - prints "0"
>>x = 3
>>
>> def g():
>>print x # exception
>>var x = 3
>>
>
> what are the exact semantics of "var" ? a
Marcin 'Qrczak' Kowalczyk wrote:
> It should be:
>
> var x = 0
> def f():
>print x
>x = 3
>
> for the global variable, and:
>
> var x = 0
> def f():
>var x
>print x
>x = 3
>
> for the local variable.
>
> There are a few sane choices for the semantics of 'var':
>
> 1. The varia
Neil Toronto wrote:
> Heck no. An assignment would modify an existing variable only.
what's an "existing variable"? how would STORE_GLOBAL work under your
proposal?
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/
Fredrik Lundh wrote:
> Neil Toronto wrote:
>
>
>> Heck no. An assignment would modify an existing variable only.
>>
>
> what's an "existing variable"? how would STORE_GLOBAL work under your
> proposal?
>
I haven't got a clue what STORE_GLOBAL is, apart from the fact that it
looks lik
Neil Toronto wrote:
> Marcin 'Qrczak' Kowalczyk wrote:
>
>> It should be:
>>
>> var x = 0
>> def f():
>>print x
>>x = 3
>>
>> for the global variable, and:
>>
>> var x = 0
>> def f():
>>var x
>>print x
>>x = 3
>>
>> for the local variable.
>>
>> There are a few sane choices
Le lundi 09 octobre 2006 à 12:49 +0200, Georg Brandl a écrit :
> They wouldn't be "local" unless declared with "var", I assume.
Which is a sure way to cause all kind of frigging bugs if you forget to
put "var", because then your variable is global, which is fine when it's
a plain int or string, n
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 s
Antoine Pitrou wrote:
> Le lundi 09 octobre 2006 à 12:49 +0200, Georg Brandl a écrit :
>> They wouldn't be "local" unless declared with "var", I assume.
>
> Which is a sure way to cause all kind of frigging bugs if you forget to
> put "var", because then your variable is global, which is fine when
Antoine Pitrou <[EMAIL PROTECTED]> writes:
> Which is a sure way to cause all kind of frigging bugs if you forget to
> put "var", because then your variable is global, which is fine when it's
> a plain int or string, not when it's a complex object whose mere
> existence changes lots of things.
Wh
Neil Toronto <[EMAIL PROTECTED]> wrote:
> Fredrik Lundh wrote:
> > Neil Toronto wrote:
> >> Heck no. An assignment would modify an existing variable only.
> >>
> >
> > what's an "existing variable"? how would STORE_GLOBAL work under your
> > proposal?
>
> I haven't got a clue what STORE_GL
On 2006-10-09 15:47:09 +0200, Jim Jewett wrote:
> Because it is ambiguous. The print indicates that you want (read)
> access to an existing variable, but the assignment indicates that you
> want (write) access to that variable. Did you mean
>
> x = 0
> def f():
> global x # modi
Josiah Carlson <[EMAIL PROTECTED]> writes:
> From what I can tell, the only thing that your 'var' keyword does is
> ambiguate the global vs. local case,
No, it can select between any of outer scopes.
It also allows to put globals in an array instead of a dictionary,
making them as fast as locals
Marcin 'Qrczak' Kowalczyk wrote:
> It also allows to put globals in an array instead of a dictionary,
> making them as fast as locals.
so module namespaces will no longer be populated by *executing* the
module contents?
what would happen if you tried to execute the following code?
def foo(
Fredrik Lundh <[EMAIL PROTECTED]> writes:
>> It also allows to put globals in an array instead of a dictionary,
>> making them as fast as locals.
>
> so module namespaces will no longer be populated by *executing* the
> module contents?
They would, but the set of global names except 'from module
Marcin 'Qrczak' Kowalczyk wrote:
> Fredrik Lundh <[EMAIL PROTECTED]> writes:
>
>>> It also allows to put globals in an array instead of a dictionary,
>>> making them as fast as locals.
>> so module namespaces will no longer be populated by *executing* the
>> module contents?
>
> They would, but
Antoine Pitrou wrote:
> Le lundi 09 octobre 2006 à 12:49 +0200, Georg Brandl a écrit :
>
>> They wouldn't be "local" unless declared with "var", I assume.
>>
>
> Besides, in a well-written program, you will mostly access local
> variables (and attributes and methods), so let's make the clea
"Marcin 'Qrczak' Kowalczyk" <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson <[EMAIL PROTECTED]> writes:
>
> > From what I can tell, the only thing that your 'var' keyword does is
> > ambiguate the global vs. local case,
>
> No, it can select between any of outer scopes.
No. It can't select betw
27 matches
Mail list logo
