On Fri, Jul 6, 2018 at 10:17 AM, Guido van Rossum wrote:
>> I'm still wondering if it might make sense to define a new
>> "TargetScopeError" subclass of SyntaxError for that last case, since it
>> isn't the assignment expression syntax itself that's the problem: it's where
>> that expression is lo
On Thu, Jul 5, 2018 at 3:35 PM Nick Coghlan wrote:
> Guido did fully specify this in his post on "__parentlocal" scoping, in
> response to my request that this be clearly spelled out in the PEP (that
> specification just hasn't been rolled back into the PEP yet).
>
Having written it up that way,
On Thu, Jul 5, 2018 at 3:45 PM Nick Coghlan wrote:
>
>
> On Thu., 5 Jul. 2018, 3:17 pm Guido van Rossum, wrote:
>
>> Let me be slightly contrarian. :-)
>>
>> On Wed, Jul 4, 2018 at 9:12 PM Chris Angelico wrote:
>>
>>> Definitely against augmentation, for several reasons:
>>>
>>> 1) Spelling - s
On Thu., 5 Jul. 2018, 3:17 pm Guido van Rossum, wrote:
> Let me be slightly contrarian. :-)
>
> On Wed, Jul 4, 2018 at 9:12 PM Chris Angelico wrote:
>
>> Definitely against augmentation, for several reasons:
>>
>> 1) Spelling - should it be :+= or +:= ?
>>
>
> That one's easy. As Nick's (withdra
On Thu., 5 Jul. 2018, 10:23 am Steve Dower, wrote:
> On 04Jul2018 1518, Tim Peters wrote:
> > The only new thing is specifying the scope of `a`, where "local to f"
> > means exactly the same thing as for any other name local to a function
> > today. So far as the PEP semantics go, it doesn't eve
On Thu, Jul 5, 2018 at 3:15 PM, Guido van Rossum wrote:
> Let me be slightly contrarian. :-)
>
> On Wed, Jul 4, 2018 at 9:12 PM Chris Angelico wrote:
>> 2) Is the result of the expression the modified value or the original?
>
> Someone (sadly I forget who) showed, convincingly (to me anyways :-)
Let me be slightly contrarian. :-)
On Wed, Jul 4, 2018 at 9:12 PM Chris Angelico wrote:
> Definitely against augmentation, for several reasons:
>
> 1) Spelling - should it be :+= or +:= ?
>
That one's easy. As Nick's (withdrawn) PEP 577 shows it should be simply
`+=`.
> 2) Is the result of th
On Thu, Jul 5, 2018 at 1:28 PM, Ivan Pozdeev via Python-Dev
wrote:
> Victor Stinner in "Assignment expression and coding style: the while True
> case" and others have brought to attention
>
> that the AE as currently written doesn't support all the capabilities of the
> assignment statement, namel
[Ivan Pozdeev]
> Victor Stinner in "Assignment expression and coding style: the while
> True case" and others have brought to attention
>
> that the AE as currently written doesn't support all the capabilities of
> the assignment statement, namely:
>
> * tuple unpacking
> * augmented assignment
>
Victor Stinner in "Assignment expression and coding style: the while
True case" and others have brought to attention
that the AE as currently written doesn't support all the capabilities of
the assignment statement, namely:
* tuple unpacking
* augmented assignment
(I titled the letter "all c
[Steve Dower]
> In that case, please provide more examples of how it should work when
> the assignment expression appears to define a variable in a scope that
> is not on the call stack.
>
Sorry, I'm not clear what you're asking about. Python's scopes are
determined statically, at compile-time -
On Thu, Jul 5, 2018 at 10:20 AM, Steve Dower wrote:
> On 04Jul2018 1518, Tim Peters wrote:
>> The only new thing is specifying the scope of `a`, where "local to f"
>> means exactly the same thing as for any other name local to a function
>> today. So far as the PEP semantics go, it doesn't even m
On 04Jul2018 1518, Tim Peters wrote:
> The only new thing is specifying the scope of `a`, where "local to f"
> means exactly the same thing as for any other name local to a function
> today. So far as the PEP semantics go, it doesn't even matter whether
> an implementation _does_ implement some fo
[Steve Dower]
> Okay, so as far as the specification goes, saying "assignment
> > expressions in comprehensions get or create a cell variable in the
> > defining scope and update its value" satisfies me just fine (or some
> > other wording that more closely mirrors the actual behaviour - all my
On 04Jul2018 1021, Tim Peters wrote:
Same as now, `i` is local to the synthetic nested function created for
the genexp. The scope of `a` is determined by pretending the assignment
occurred in the block containing the outermost (textually - static
analysis) comprehension. In this case, `a = an
Just a quickie:
[Steve Dower]
> > The PEP uses the phrase "an assignment expression
> occurs in a comprehension" - what does this mean?
It's about static analysis of the source code, at compile-time, to
establish scopes. So "occurs in" means your eyeballs see an assignment
expression in a compr
Thanks for thinking about the details! I want to answer all of these but
right now I have some social obligations so it may be a few days. I expect
the outcome of this investigation to result in an improved draft for PEP
572.
On Wed, Jul 4, 2018 at 7:29 AM Steve Dower wrote:
> Now that it's a do
Now that it's a done deal, I am closely reviewing the semantics section
of PEP 572. (I had expected one more posting of the final PEP, but it
seems the acceptance came somewhere in a thread that was already muted.)
Since there has been no final posting that I'm aware of, I'm referring
to https://w
18 matches
Mail list logo
