[Fredrik Lundh]
def counter(num):
num = mutable_int(num)
def inc():
num += 1
return num
return inc
feel free to replace that += with an .add(1) method call; the point
wasn't the behaviour of augmented assigment, the point
On 7/12/06, Fredrik Lundh [EMAIL PROTECTED] wrote:
Boris Borcic wrote:
note that most examples of this type already work, if the target type is
mutable, and implement the right operations:
def counter(num):
num = mutable_int(num)
def inc():
Terry Reedy wrote:
Boris Borcic [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
I agree with you (and argued it in scopes vs augmented assignment vs
sets
recently) that mutating would be sufficient /if/ the compiler would view
augmented assignment as mutations operators :
Boris Borcic wrote:
note that most examples of this type already work, if the target type is
mutable, and implement the right operations:
def counter(num):
num = mutable_int(num)
def inc():
num += 1
return num
return inc
Ka-Ping Yee wrote:
On Mon, 10 Jul 2006 [EMAIL PROTECTED] wrote:
I think Talin's got a point though. It seems hard to find one short English
word that captures the essence of the desired behavior. None of the words
in his list seem strongly suggestive of the meaning to me. I suspect that
Jeremy Hylton wrote:
To express this email in the positive form:
1. Reserved words should be real words.
2. The meaning of the word should be clear.
3. Put statements in positive form. (Strunk White)
4. The word should sound good.
agreed. a word should describe what a thing is, not what
Talin wrote:
I also think that it won't be a complete disaster if we do nothing at
all - there *are* existing ways to deal with this problem; there are
even some which aren't hackish and non-obvious. For example, its easy
enough to create an object which acts as an artificial scope:
Talin wrote:
Ka-Ping Yee wrote:
On Mon, 10 Jul 2006 [EMAIL PROTECTED] wrote:
I think Talin's got a point though. It seems hard to find one short English
word that captures the essence of the desired behavior. None of the words
in his list seem strongly suggestive of the meaning to
Fuzzyman wrote:
I've often found it a nuisance that you can't instantiate an 'object',
to use as a mutable 'namespace', but instead have to define an arbitrary
empty class.
What happened to the 'namespace' proposal ?
The code and the pre-PEP [1] are still out there, but Carlos, Steve and I
outbound x = 1
x = 2
evaluating using Jeremy Hilton's' list:
1. is a real word
2. For me - in python - it would mean: Is found in 'outer' scope and
is already bound.
And the literal meaning of 'outbound 'headed away' [1] is pretty
darn close to what I mean when I spell the usual mutables
Robin Bryce wrote:
outbound x = 1
FWINW, to me 'nonlocal' clearly and immediately tells you what you need
to know about the variable.
'outbound' has no programming associations for me (it makes me think of
'outward bound' and roaming the great outdoors). So negative or not I'm
+1 on nonlocal
Matthew Barnes wrote:
its
meaning in C/C++ (i.e. the symbol is defined outside of the current
scope).
It means more than that -- it means defined outside
the current *file*. That's much too drastic for
what we want.
--
Greg
___
Python-Dev mailing
On Mon, 10 Jul 2006 [EMAIL PROTECTED] wrote:
I think Talin's got a point though. It seems hard to find one short English
word that captures the essence of the desired behavior. None of the words
in his list seem strongly suggestive of the meaning to me. I suspect that
means one's ultimately
On 7/10/06, Ka-Ping Yee [EMAIL PROTECTED] wrote:
On Mon, 10 Jul 2006 [EMAIL PROTECTED] wrote:
I think Talin's got a point though. It seems hard to find one short English
word that captures the essence of the desired behavior. None of the words
in his list seem strongly suggestive of the
What's wrong with nonlocal? I don't think i've seen an argument
against that one so far (from Talin or others).
It sounds a bit awkward to me. Also, it would be nice if the keyword
indicated which scope was operative.
If I've followed the discussions correctly, I think the parent scope
would
On 7/10/06, Ka-Ping Yee [EMAIL PROTECTED] wrote:
What's wrong with nonlocal? I don't think i've seen an argument
against that one so far (from Talin or others).
On Mon, 10 Jul 2006, Jeremy Hylton wrote:
It's a made-up word. You won't find it in the dictionary and the
google define: query
On 7/10/06, Jeremy Hylton [EMAIL PROTECTED] wrote:
On 7/10/06, Ka-Ping Yee [EMAIL PROTECTED] wrote: On Mon, 10 Jul 2006 [EMAIL PROTECTED] wrote: I think Talin's got a point though.It seems hard to find one short English
word that captures the essence of the desired behavior.None of the words
Guido van Rossum wrote:
Then let's allow
nonlocal x = 12
as a shortcut for
nonlocal x
x = 12
I thought you didn't like that, because in
nonlocal x = 12
x = 42
it's not clear whether these are talking about the same
x or not.
--
Greg
On 7/10/06, Ka-Ping Yee [EMAIL PROTECTED] wrote:
On 7/10/06, Ka-Ping Yee [EMAIL PROTECTED] wrote:
What's wrong with nonlocal? I don't think i've seen an argument
against that one so far (from Talin or others).
On Mon, 10 Jul 2006, Jeremy Hylton wrote:
It's a made-up word. You won't find
On Mon, 2006-07-10 at 16:43 -0400, Jeremy Hylton wrote:
To express this email in the positive form:
1. Reserved words should be real words.
2. The meaning of the word should be clear.
3. Put statements in positive form. (Strunk White)
4. The word should sound good.
As I've been following
On 7/10/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I don't think the keyword should indicate a scope.
I'd prefer it if LOAD_WHATEVER just percolated its way up the chain of
cells (or could be identified at compile time by inspecting the AST as I
think Guido intends) without the programmer
On Sun, 9 Jul 2006, Andrew Koenig wrote:
Sounds reasonable to me. If we're talking py3k I'd chuck global as a
keyword though and replace it with something like outer.
I must say that I don't like outer any more than I like global. The
problem is that in both cases we are selecting the
Ka-Ping Yee wrote:
On Sun, 9 Jul 2006, Andrew Koenig wrote:
Sounds reasonable to me. If we're talking py3k I'd chuck global as a
keyword though and replace it with something like outer.
I must say that I don't like outer any more than I like global. The
problem is that in both cases we are
Talin wrote:
Some alternatives:
use x
using x
with x -- recycle a keyword?
reuse x
use extant x
share x
common x
same x
borrow x
existing x
Although, to be perfectly honest, the longer this discussion goes on,
the more that I
On 7/9/06, Talin [EMAIL PROTECTED] wrote:
Talin wrote:
Some alternatives:
use x
using x
with x -- recycle a keyword?
reuse x
use extant x
share x
common x
same x
borrow x
existing x
Of these, I like reuse, share,
Evan Simpson wrote:
I'd like to toss one more variant into the mix. If we really need to
address variables in an intermediate scope, the most explicit way
that I can think of doing so is to write (using Philip's example):
def counter(num):
scope as outer # outer is an arbitrary
[EMAIL PROTECTED] wrote:
jan-python So.. are we only thinking about implementing this outer
jan-python scope assignment because there's lots of talk about it on
jan-python the list, ...
:-)
jan-python ... or are there actually use cases that would become
jan-python
Just van Rossum wrote:
Why couldn't at least augmented assignment be implicitly rebinding? It
has been suggested before (in the context of a rebinding operator), but
I'm wondering, is this also off the table?
def counter(num):
def inc():
num += 1
Kevin Jacobs [EMAIL PROTECTED] wrote:
Why not extend the interface to the locals builtin and add a __getitem__
that returns a proxy to access locals defined in other lexical scopes
via __{get/set/del}attr_:
def counter(num):
num = 1
def inc():
locals[1].num += 1
At 09:56 PM 7/6/2006 -0400, Kevin Jacobs [EMAIL PROTECTED] wrote:
Why not extend the interface to the locals builtin and add a __getitem__
that returns a proxy to access locals defined in other lexical scopes via
__{get/set/del}attr_:
def counter(num):
num = 1
def inc():
Guido Well, personally I'm for allowing full rebinding semantics but
Guido only when a 'global' (or 'nonlocal') statement is used
Guido first. Making augmented assignment automatically imply 'global'
Guido etc. seems too magical to me.
So, if I understand correctly, in the
On 7/8/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Guido Well, personally I'm for allowing full rebinding semantics but
Guido only when a 'global' (or 'nonlocal') statement is used
Guido first. Making augmented assignment automatically imply 'global'
Guido etc. seems too
Phillip J. Eby wrote:
At 07:27 PM 7/5/2006 +0200, Guido van Rossum wrote:
However I still don't believe global has the stretchiness in its
meaning that you claim it has. Have you ever heard a Python programmer
talking about closures use the word global variable?
Are there any other native
Michael Chermside [EMAIL PROTECTED] writes:
Phillip Eby writes:
I don't see a problem with requiring '.x' to be used for both
reading and writing of outer-scope names; it just shouldn't be
required for an outer-scope name that you don't rebind in the
current scope.
def
Ka-Ping Yee wrote:
On Wed, 5 Jul 2006, Guido van Rossum wrote:
On 7/5/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
Using the classic nonsense example:
def counter(num):
def inc():
.num += 1
return .num
return inc
Would this also use ..num
So.. are we only thinking about implementing this outer scope
assignment because
there's lots of talk about it on the list, or are there actually use
cases that
would become clearer if assigning to an outer scope variable was allowed? I
tend to think that almost _any_ piece of code that could be
jan-python So.. are we only thinking about implementing this outer
jan-python scope assignment because there's lots of talk about it on
jan-python the list, ...
:-)
jan-python ... or are there actually use cases that would become
jan-python clearer if assigning to an outer
However I still don't believe global has the stretchiness in its
meaning that you claim it has. Have you ever heard a Python programmer
talking about closures use the word global variable?
I guess the term I've heard most often is free variable, but I wouldn't be
surprised if I saw the term
On 7/6/06, Guido van Rossum [EMAIL PROTECTED] wrote:
+1 on nonlocal.I think that the := operator is also in case (b), but as I don't likeit I'm find with not mentioning it. :-)Could someone write a PEP for this? Doesn't have to be very long butI'd like it to summarize the main options proposed and
At 10:05 AM 7/6/2006 -0500, [EMAIL PROTECTED] wrote:
jan-python So.. are we only thinking about implementing this outer
jan-python scope assignment because there's lots of talk about it on
jan-python the list, ...
:-)
jan-python ... or are there actually use cases that would
Talin wrote:
I propose to create a new type of scoping rule, which I will call
explicit lexical scoping, that will co-exist with the current
implicit scoping rule that exists in Python today.
I'd like to toss one more variant into the mix. If we really need to
address variables in an
On Thu, 06 Jul 2006 18:28:12 +0200, Phillip J. Eby [EMAIL PROTECTED]
wrote:
Here's the reason I think this keeps coming up, and why Guido's just
use a class argument doesn't really address the actual problem that's
taking place.
I agree this argument is not generally applicable in every
At 01:00 AM 7/7/2006 +0200, Jan Kanis wrote:
On Thu, 06 Jul 2006 18:28:12 +0200, Phillip J. Eby [EMAIL PROTECTED]
wrote:
Here's the reason I think this keeps coming up, and why Guido's just
use a class argument doesn't really address the actual problem that's
taking place.
I agree this argument
On Fri, 07 Jul 2006 01:25:19 +0200, Phillip J. Eby [EMAIL PROTECTED]
wrote:
- or so it feels like to the person who's experiencing it.
Have you ever been that person, or come across such a situation?
Many times. The hard thing about trying to provide use cases for this
is that of
On 7/6/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
Here's the reason I think this keeps coming up, and why Guido's just use a
class argument doesn't really address the actual problem that's taking place.
(And note that I've recently gone on record as doubting that argument myself.)
When you
On 7/6/06, Evan Simpson [EMAIL PROTECTED] wrote:
Talin wrote: I propose to create a new type of scoping rule, which I will call explicit lexical scoping, that will co-exist with the current implicit scoping rule that exists in Python today.
I'd like to toss one more variant into the mix.If we
At 05:49 AM 7/5/2006 +0200, Guido van Rossum wrote:
* Alternate spelling of outer names when binding (e.g. .x = whatever to
bind an outer x)
We looked at and rejected globals.x = whatever. I think the same
reasoning applies here.
I thought the 'globals.x' proposal required that 'x' always be
On 7/5/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 05:49 AM 7/5/2006 +0200, Guido van Rossum wrote:
* Alternate spelling of outer names when binding (e.g. .x = whatever to
bind an outer x)
We looked at and rejected globals.x = whatever. I think the same
reasoning applies here.
I
On Wednesday 05 July 2006 18:21, Guido van Rossum wrote:
Would this also use ..num to refer to num in an outer scope two
levels removed?
Ew!
I don't want to even think about debugging
...x
vs
x
Anthony
--
Anthony Baxter [EMAIL PROTECTED]
It's never too late to have a happy
Sorry, I should have added a wink... :-)
On 7/5/06, Anthony Baxter [EMAIL PROTECTED] wrote:
On Wednesday 05 July 2006 18:21, Guido van Rossum wrote:
Would this also use ..num to refer to num in an outer scope two
levels removed?
Ew!
I don't want to even think about debugging
...x
vs
Guido van Rossum wrote:
On 7/5/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 12:18 AM 7/5/2006 +0200, Guido van Rossum wrote:
I don't see anything else that's attractive. The realistic options are:
1. do nothing
2. extend global's meaning
3. add outer keyword
Did you also consider and
Guido van Rossum wrote:
Would this also use ..num to refer to num in an outer scope two levels
removed?
I realize this was a wink, but it is a valid problem with the
dot-proposal.
def foo(n):
def bar(n):
def baz():
return .n
So, which 'n' outer 'n' is being referenced? Seems
Guido van Rossum [EMAIL PROTECTED] wrote:
1. do nothing
2. extend global's meaning
3. add outer keyword
2.5. extend global syntax to cover both [really global] and [innermost
matching scope].
eg.
global x, y outer # trailing non-keyword
global in x, y # re-use keyword
not
Guido van Rossum wrote:
On 7/5/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
Did you also consider and reject:
* Alternate binding operators (e.g. :=, .=, etc.)
Brr.
That's too bad :(
I still find a rebinding operator (:= being my favorite) much, *much*
more appealing than any of the
On 7/5/06, Just van Rossum [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
On 7/5/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
Did you also consider and reject:
* Alternate binding operators (e.g. :=, .=, etc.)
Brr.
That's too bad :(
I still find a rebinding operator (:= being
2006/7/5, Just van Rossum [EMAIL PROTECTED]:
Guido van Rossum wrote:
On 7/5/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
Did you also consider and reject:
* Alternate binding operators (e.g. :=, .=, etc.)
Brr.
That's too bad :(
I still find a rebinding operator (:= being my
Guido van Rossum wrote:
Hallo broer! :-)
Yo :)
I wonder what this should mean then:
def outer():
def inner():
x := 1
What is x's scope?
UnboundVariableError: variable 'x' referenced before assignment
Or a SyntaxError if the compiler can detect it.
Also, a := operator allows
I know this is very similar to the global.x = syntax, which
was already shot down?, but wouldn't allowing access to a
functions locals from within, by prefixing the name, be a good
way to disambiguate what happens (instead of any operator to
indicate outer scope, like .x = 3 or the like)? I guess
Marek Baczek Baczyñski wrote:
I suggest - as an assignment operator instead of := - it's used in
OCaml and it looks *very* different, yet still makes sense.
Except it's currently valid Python syntax:
x = 0
x - 42
False
Just
___
Barry Clearly we need the as if in operator:
Why not be more direct?
x = 0
def foo():
x = 1
def bar():
x = 2
def baz():
x in foo = 3
x in global += 1
By naming the function in which the binding is to occur you avoid
On 5 jul 2006, at 11.40, Scott Dial wrote:
Guido van Rossum wrote:
Would this also use ..num to refer to num in an outer scope two
levels removed?
I realize this was a wink, but it is a valid problem with the
dot-proposal.
def foo(n):
def bar(n):
def baz():
return .n
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 5, 2006, at 9:39 AM, [EMAIL PROTECTED] wrote:
Barry Clearly we need the as if in operator:
Why not be more direct?
Sure, why not? :)
Then we can reserve the as if operator for those things that Guido
has rejected, but that we sneak
At 10:21 AM 7/5/2006 +0200, Guido van Rossum wrote:
Thanks for bringing this up. I'm not sure what I think of it yet. One
problem I see is that there might end up being two ways to reference
variables in outer scopes: .num if you plan to assign to it, or just
num if you only reference it. I find
At 05:40 AM 7/5/2006 -0400, Scott Dial wrote:
Guido van Rossum wrote:
Would this also use ..num to refer to num in an outer scope two levels
removed?
I realize this was a wink, but it is a valid problem with the
dot-proposal.
Actually, it isn't. :) See below.
def foo(n):
def bar(n):
On 7/5/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
By the way, an interesting thought for Py3K is that you could maybe use
this syntax to do away with explicit 'self', if you consider the class'
namespace to be part of a function's closure.
Sorry, but now I am *definitely* -1.
--
--Guido van
On 7/5/06, Michael Chermside [EMAIL PROTECTED] wrote:
Guido writes:
[discussion of how to fix the can't-bind-outer-scope-vars wart]
I think we have to continue to search for a solution that extends the
idea of global declarations.
I've proposed extending its meaning to refer to the
Phillip Eby writes:
I don't see a problem with requiring '.x' to be used for both
reading and writing of outer-scope names; it just shouldn't be
required for an outer-scope name that you don't rebind in the
current scope.
def counter(num):
def inc():
.num
Phillip Eby writes:
The big problem that comes to mind with that idea is that it makes
it impossible to have argument names that are the same as attribute
names, unless the 'whee'/'.whee' prohibition were relaxed. :( But
it's an intriguing thought, nonetheless.
My three-year-old has
At 07:27 PM 7/5/2006 +0200, Guido van Rossum wrote:
However I still don't believe global has the stretchiness in its
meaning that you claim it has. Have you ever heard a Python programmer
talking about closures use the word global variable?
Are there any other native speakers who side with
Marek Baczek Baczyński wrote:
I suggest - as an assignment operator instead of := - it's used in
OCaml and it looks *very* different, yet still makes sense.
But assigning to an outer scope isn't *very* different,
it's only slightly different.
--
And now for something slightly different...
Simon Percivall wrote:
def foo():
def bar():
foo.x = 3
That already had a different meaning - it assigns
to an attribute of the function object created by
executing def foo().
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
[EMAIL PROTECTED] wrote:
By naming the function in which the binding is to occur you avoid problems
of someone coming along and adding or deleting functions between the
assignment (in baz) and the target of the assignment (x in foo) but then
forgetting to increment or decrement the counters
On Wed, 5 Jul 2006, Guido van Rossum wrote:
On 7/5/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
Using the classic nonsense example:
def counter(num):
def inc():
.num += 1
return .num
return inc
Would this also use ..num to refer to
+1 on nonlocal.
I think that the := operator is also in case (b), but as I don't like
it I'm find with not mentioning it. :-)
Could someone write a PEP for this? Doesn't have to be very long but
I'd like it to summarize the main options proposed and discuss them,
like I did for the switch PEP.
This is sort of a re-do of an earlier proposal which seems to have
gotten lost in the shuffle of the larger debate.
I propose to create a new type of scoping rule, which I will call
explicit lexical scoping, that will co-exist with the current
implicit scoping rule that exists in Python today.
Talin wrote:
This is sort of a re-do of an earlier proposal which seems to have
gotten lost in the shuffle of the larger debate.
I propose to create a new type of scoping rule, which I will call
explicit lexical scoping, that will co-exist with the current
implicit scoping rule that exists
Borrowing from Perl, the keyword 'my' is used to declare an explicitly
scoped variable:
def f1():
my x = 1
def f2():
x = 2 # Does not create a new x
In the above example, the statement 'my x = 1' declares that the scope
of the variable 'x' is the outer
Please move this to the python-3000 list.
Also please explain what problem you are solving before proposing a solution.
I note that we are seeing quite a flurry of language change proposals.
I have to recommend restraint; I *don't* want to turn the entire
language upside down. That's not a
On 7/4/06, Talin [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
Also please explain what problem you are solving before proposing a
solution.
Actually, the problem I am trying to solve is the debate on the
mailing list. That is, I listen to what people are asking for, and what
On 7/5/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 12:18 AM 7/5/2006 +0200, Guido van Rossum wrote:
I don't see anything else that's attractive. The realistic options are:
1. do nothing
2. extend global's meaning
3. add outer keyword
Did you also consider and reject:
* Alternate
80 matches
Mail list logo
