Greg Ewing wrote:
> Besides, the BDFL is going to do whatever he wants
> anyway, so let's just leave him to get on with it. :-)
but where is he? has anyone seen him lately ?
___
Python-3000 mailing list
[email protected]
http://mail.python.org/
On 11/3/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Greg Ewing wrote:
>
> > Besides, the BDFL is going to do whatever he wants
> > anyway, so let's just leave him to get on with it. :-)
>
> but where is he? has anyone seen him lately ?
Sure, he's been busy at work and sick recently. He'll pro
Ka-Ping Yee wrote:
> Right now, in any given context, "the global namespace" has a clear
> meaning: the namespace shared by the whole file. With the new meaning
> of the "global" keyword, "global namespace" becomes meaningless no
> matter what the context. In Python, the concepts of "global", "gl
Fredrik Lundh wrote:
> Greg Ewing wrote:
>
>> Besides, the BDFL is going to do whatever he wants
>> anyway, so let's just leave him to get on with it. :-)
>
> but where is he? has anyone seen him lately ?
Also bear in mind that the BDFL doesn't simply make pronouncements in a
vacuum...he reall
Ka-Ping Yee wrote:
> On Fri, 3 Nov 2006, Greg Ewing wrote:
>>> Before it is reasonable to change the meaning of "global", we would
>>> need to have coherent answers to these questions:
>>>
>>> 1. What is the global namespace?
>> Under the proposal, there is no such thing as
>> "the" global nam
> How about [...] using 'parent' as the keyword?
I once proposed 'parent' in a similar thread a long time ago.
It's a non-starter because it's a commonly used variable name.
Mike
___
Python-3000 mailing list
[email protected]
http://mail.python
Mike Krell wrote:
>> How about [...] using 'parent' as the keyword?
>
> I once proposed 'parent' in a similar thread a long time ago.
>
> It's a non-starter because it's a commonly used variable name.
>
>Mike
I thought it might be.
How about. __parent__
Just kidding, (I think), of c
Ron Adam wrote:
> Mike Krell wrote:
>
>>> How about [...] using 'parent' as the keyword?
>>>
>> I once proposed 'parent' in a similar thread a long time ago.
>>
>> It's a non-starter because it's a commonly used variable name.
>>
>>Mike
>>
>
>
> I thought it might be.
>
> How abo
Ron Adam <[EMAIL PROTECTED]> writes:
> How about limiting nonlocal to just the immediate parent scope and
> using 'parent' as the keyword?
Please don't put unnecessary limits.
There are two ways to refer to a variable: read it or assign it.
Currently reading doesn't create a new variable, while
Ka-Ping Yee wrote:
> Hi folks,
>
> I have finally completed a draft of a PEP on rebinding of names
> in outer scopes. I've tried to go back and gather all of the
> (amazingly numerous) proposals -- if i've forgotten or misattributed
> any, let me know and i'll be happy to correct them.
>
> I look
On Fri, 3 Nov 2006, Neil Toronto wrote:
> Is there any particular reason this *must* be a Py3k PEP? (Aside from
> the fact that we're discussing it on the Py3k list, of course.) Some of
> the solutions discussed for historical context would *definitely* be bad
> ideas for a 2.x (as would changing t
On Thu, 2 Nov 2006, Christian Tanzer wrote:
> As you allow
>
> nonlocal x, y, z
>
> and
>
> x, y, z = 1, 2, 3
>
> is legal Python (and does the right thing), why not allow
>
> nonlocal x, y, z = 1, 2, 3
>
> too?
>
> That's one less rule needed to be learned and enforced.
I suppose that
Le vendredi 03 novembre 2006 à 15:19 -0600, Ka-Ping Yee a écrit :
> I suppose that's fine. Also i guess
>
> nonlocal x = y = 0
That's ambiguous.
Is only "x" nonlocal, or are both "x" and "y"?
What's the point anyway? if you write "nonlocal x = 0", it means you
aren't reusing the variable v
On Fri, 3 Nov 2006, Antoine Pitrou wrote:
> Le vendredi 03 novembre 2006 à 15:19 -0600, Ka-Ping Yee a écrit :
> > I suppose that's fine. Also i guess
> >
> > nonlocal x = y = 0
>
> That's ambiguous.
> Is only "x" nonlocal, or are both "x" and "y"?
Only x is nonlocal.
nonlocal x = y = 0
Le vendredi 03 novembre 2006 à 16:22 -0600, Ka-Ping Yee a écrit :
> Only x is nonlocal.
>
> nonlocal x = y = 0
>
> is equivalent to
>
> nonlocal x; x = y = 0
Perhaps, but the point is that it's non-intuitive from reading.
Just like the old "char * x, y" annoyance in C.
> The point is t
Nick Coghlan wrote:
> A new keyword, on the other hand, allows the list to be split relatively
> cleanly into four possible locations:
>
> 1. function locals of the current function (local variables)
> 2. function locals of an enclosing function (closure variables)
> 3. module globals (global va
Ka-Ping Yee wrote:
> nonlocal x = y = 0
I don't really like the idea of allowing assignment in
the nonlocal/global/whatever statement. It leads to
questions like what happens if some assignments in a
scope are qualified with nonlocal and others aren't.
Certainly answers can be given, but it'
Ka-Ping Yee wrote:
> nonlocal x = y = 0
>
> is equivalent to
>
> nonlocal x; x = y = 0
This is far from obvious. And what happens if
you want both x and y to be nonlocal? Can you
write
nonlocal x = nonlocal y = 0
If so, this is getting even more complicated
for very little benefit.
Greg Ewing wrote:
> Ka-Ping Yee wrote:
>
>
>> nonlocal x = y = 0
>>
>> is equivalent to
>>
>> nonlocal x; x = y = 0
>>
>
> This is far from obvious. And what happens if
> you want both x and y to be nonlocal? Can you
> write
>
>nonlocal x = nonlocal y = 0
>
> If so, this is gett
Greg Ewing wrote:
> I don't see what's so important about treating the
> module namespace differently from other lexically
> enclosing scopes for the purpose of resolving names.
> Especially only for *assignment* to names.
>
> For read access, we seem to get on just fine without
> any keywords to
Neil Toronto wrote:
>>> The point is to make the statement easy to explain.
>>>
>> It's even easier to explain if assignment isn't
>> allowed at all.
>>
>
> Sorry about the "mee to" post, but me too: +1 on no assignment allowed.
> I can't think of any way to do it that would be intuitive
Neil Toronto wrote:
> Ka-Ping Yee wrote:
>> Hi folks,
>>
>> I have finally completed a draft of a PEP on rebinding of names
>> in outer scopes. I've tried to go back and gather all of the
>> (amazingly numerous) proposals -- if i've forgotten or misattributed
>> any, let me know and i'll be happy
Ron Adam wrote:
> How about limiting nonlocal to just the immediate parent scope and using
> 'parent' as the keyword?
That could lead to confusing situations. What should
the following do:
def f():
x = 42
def g():
def h():
parent x
x = 88
Should the assignment
23 matches
Mail list logo
