[Guido, makes peace with `identifier := expression`]
> ...
> I am fine with this, it certainly seems the easiest to implement, with the
> fewest corner cases, and the easiest restriction to explain.
>
> (I was thinking there would be a use case for basic tuple unpacking, like
> seen a lot in for-lo
On Wed, Apr 18, 2018 at 10:13:58AM +1000, Chris Angelico wrote:
[regarding comprehensions]
> The changes here are only to edge and corner cases, other than as they
> specifically relate to assignment expressions. The current behaviour
> is intended to "do the right thing" according to people's
>
On Tue, Apr 17, 2018 at 3:23 PM, Tim Peters wrote:
> [Tim]
> >> I'll channel that Guido would be happiest if this rule were followed:
> >>
> >> Given an assignment statement using "=", the meaning is the same if
> >> "=" is replaced with ":=".
>
Thanks for channeling me. :=)
I'd like Guido to c
On Wed, Apr 18, 2018 at 7:53 AM, Terry Reedy wrote:
> On 4/17/2018 3:46 AM, Chris Angelico wrote:
>
>> Abstract
>>
>>
>> This is a proposal for creating a way to assign to names within an
>> expression.
>
>
> I started at -something as this is nice but not necessary. I migrated to
> +som
On 2018-04-17 22:53, Terry Reedy wrote:
On 4/17/2018 3:46 AM, Chris Angelico wrote:
[snip]
Augmented assignment is not supported in expression form::
>>> x +:= 1
File "", line 1
x +:= 1
^
SyntaxError: invalid syntax
I would have expected :+=, but agre
On 17/04/2018 15:01, Chris Angelico wrote:
On Tue, Apr 17, 2018 at 10:17 PM, Nick Coghlan wrote:
Style guide recommendations
===
As this adds another way to spell some of the same effects as can already be
done, it is worth noting a few broad recommendations. These c
[Tim]
>> I'll channel that Guido would be happiest if this rule were followed:
>>
>> Given an assignment statement using "=", the meaning is the same if
>> "=" is replaced with ":=".
[Chris]
> That's broadly the intention. At the moment, there are two exceptions:
>
> 1) Augmented assignment isn't
On 4/17/2018 1:03 PM, Yury Selivanov wrote:
Using inline assignments in "while" statements is neat, but how
often do we use "while" statements?
Beginners commonly write game and entry loops and commonly stumble over
the need to write an infinite loop and a half. The evidence is on both
pyth
On 4/17/2018 3:46 AM, Chris Angelico wrote:
Abstract
This is a proposal for creating a way to assign to names within an expression.
I started at -something as this is nice but not necessary. I migrated
to +something for the specific, limited proposal you wrote above:
expressions o
On Tue, Apr 17, 2018 at 7:55 AM, Steve Dower wrote:
> Agree with Paul. The PEP is well thought out and well presented, but I
> really don’t think we need this in Python (and I say this as someone who
> uses it regularly in C/C#).
>
> -1 on the idea; no disrespect intended toward to people who did
On Wed, Apr 18, 2018 at 5:28 AM, Tim Peters wrote:
> I'll channel that Guido would be happiest if this rule were followed:
>
> Given an assignment statement using "=", the meaning is the same if
> "=" is replaced with ":=".
That's broadly the intention. At the moment, there are two exceptions:
1
I'll channel that Guido would be happiest if this rule were followed:
Given an assignment statement using "=", the meaning is the same if
"=" is replaced with ":=".
In particular, the expression at the far right is evaluated once, and
- in case of chained assignments - is applied in turn to each
On 17 April 2018 at 16:12, Ethan Furman wrote:
> On 04/17/2018 06:26 AM, Paul Moore wrote:
>
>> I should also point out that I remain -0 on this proposal (I'd already
>> said this on python-ideas, but I should probably repeat it here). For
>> me, the use cases are mostly marginal, and the major di
On 04/17/2018 06:55 AM, Steve Dower wrote:
Agree with Paul. The PEP is well thought out and well presented, but I
really don’t think we need this in Python (and I say this as someone
who uses it regularly in C/C#).
-1 on the idea; no disrespect intended toward to people who did a lot
of w
Hi Chris,
Thank you for working on this PEP! Inline assignments is a long
requested feature and this seems to be the first serious attempt
at adding it.
That said I'm very -1 on the idea.
1. I switch between Python / JavaScript / C frequently (although
I code in Python 70% of my time.) C and
On 4/17/2018 12:46 AM, Chris Angelico wrote:
gen = (x for x in rage(10)) # NameError
gen = (x for x in 10) # TypeError (not iterable)
gen = (x for x in range(1/0)) # Exception raised during evaluation
This brings such generator expressions in line with a simple translation to
func
On Tue, Apr 17, 2018 at 2:23 AM, Chris Angelico wrote:
> Augmented assignment is currently all of these:
>
> augassign: ('+=' | '-=' | '*=' | '@=' | '/=' | '%=' | '&=' | '|=' | '^=' |
> '<<=' | '>>=' | '**=' | '//=')
>
> I'm actually not sure whether the augmented-assignment-expressio
On 04/17/2018 06:26 AM, Paul Moore wrote:
I should also point out that I remain -0 on this proposal (I'd already
said this on python-ideas, but I should probably repeat it here). For
me, the use cases are mostly marginal, and the major disadvantage is
in having two forms of assignment. Explainin
On 04/17/2018 12:46 AM, Chris Angelico wrote:
PEP: 572
Title: Assignment Expressions
Author: Chris Angelico
+1
Thanks for all the hard work, Chris! Hoping this PEP finally breaks your
streak! ;)
--
~Ethan~
___
Python-Dev mailing list
Python-De
On 04/17/2018 07:01 AM, Chris Angelico wrote:
On Tue, Apr 17, 2018 at 10:17 PM, Nick Coghlan wrote:
That ambiguity generally doesn't exist with simple name bindings (I'm
excluding execution namespaces with exotic binding behaviour from
consideration here, as the consequences of trying to work
On Tue, Apr 17, 2018 at 10:17 PM, Nick Coghlan wrote:
> Initially I thought the problem was specific to tuple unpacking
> syntax, but attempting to explain why subscript assignment and
> attribute assignments were OK made me realise that they're actually
> even worse off (since they can execute ar
From: Paul Moore
Sent: Tuesday, April 17, 2018 6:31
To: David Mertz
Cc: Nick Coghlan; Python-Dev
Subject: Re: [Python-Dev] PEP 572: Assignment Expressions
On 17 April 2018 at 14:07, Paul Moore wrote:
> On 17 April 2018 at 14:01, David Mertz wrote:
>> Strongly agree with Nick that only si
On 17 April 2018 at 14:07, Paul Moore wrote:
> On 17 April 2018 at 14:01, David Mertz wrote:
>> Strongly agree with Nick that only simple name targets should be permitted
>> (at least initially). NONE of the motivating cases use more complex targets,
>> and allowing them encourages obscurity and
On 17 April 2018 at 14:01, David Mertz wrote:
> Strongly agree with Nick that only simple name targets should be permitted
> (at least initially). NONE of the motivating cases use more complex targets,
> and allowing them encourages obscurity and code golf.
I also agree. Originally I would have s
Strongly agree with Nick that only simple name targets should be permitted
(at least initially). NONE of the motivating cases use more complex
targets, and allowing them encourages obscurity and code golf.
On Tue, Apr 17, 2018, 8:20 AM Nick Coghlan wrote:
> On 17 April 2018 at 17:46, Chris Angel
On 17 April 2018 at 17:46, Chris Angelico wrote:
> Syntax and semantics
>
>
> In any context where arbitrary Python expressions can be used, a **named
> expression** can appear. This is of the form ``target := expr`` where
> ``expr`` is any valid Python expression, and ``targe
On Tue, Apr 17, 2018 at 6:26 PM, Chris Jerdonek
wrote:
> On Tue, Apr 17, 2018 at 12:46 AM, Chris Angelico wrote:
>>
>> Having survived four rounds in the boxing ring at python-ideas, PEP
>> 572 is now ready to enter the arena of python-dev. I'll let the
>> proposal speak for itself. Be aware that
On Tue, Apr 17, 2018 at 12:46 AM, Chris Angelico wrote:
>
> Having survived four rounds in the boxing ring at python-ideas, PEP
> 572 is now ready to enter the arena of python-dev. I'll let the
> proposal speak for itself. Be aware that the reference implementation
> currently has a few test failu
201 - 228 of 228 matches
Mail list logo
