[Python-Dev] PEP 572: Assignment Expressions

2018-04-17 Thread Chris Angelico
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 failures, which I'm still working on, but to my knowledge nothing will

Re: [Python-Dev] PEP 572: Assignment Expressions

2018-04-17 Thread Chris Jerdonek
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

Re: [Python-Dev] PEP 572: Assignment Expressions

2018-04-17 Thread Chris Angelico
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

Re: [Python-Dev] PEP 572: Assignment Expressions

2018-04-17 Thread David Mertz
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

Re: [Python-Dev] PEP 572: Assignment Expressions

2018-04-17 Thread Nick Coghlan
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

Re: [Python-Dev] PEP 572: Assignment Expressions

2018-04-17 Thread Paul Moore
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.

Re: [Python-Dev] PEP 572: Assignment Expressions

2018-04-17 Thread Ethan Furman
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

Re: [Python-Dev] PEP 572: Assignment Expressions

2018-04-17 Thread Chris Angelico
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

Re: [Python-Dev] PEP 572: Assignment Expressions

2018-04-17 Thread Ethan Furman
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

Re: [Python-Dev] PEP 572: Assignment Expressions

2018-04-17 Thread Ethan Furman
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.

Re: [Python-Dev] PEP 572: Assignment Expressions

2018-04-17 Thread Steve Dower
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 work on it. Top-posted from my Windows phone

[Python-Dev] Basic test to validate win10 install?

2018-04-17 Thread Martin Gainty
Martin Gainty has shared a OneDrive file with you. To view it, click the link below. [https://r1.res.office365.com/owa/prem/images/dc-generic_20.png] errors

Re: [Python-Dev] Basic test to validate win10 install?

2018-04-17 Thread Zachary Ware
Hi Martin, On Mon, Apr 16, 2018 at 5:00 PM, Martin Gainty wrote: > I was told the python -m test are for devs only to test "auxiliary > functions" > do you have a "basic test" i can use to validate Python36 has installed > properly on Win10? The fact that the tests run at

Re: [Python-Dev] PEP 572: Assignment Expressions

2018-04-17 Thread Eric Fahlgren
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

Re: [Python-Dev] PEP 572: Assignment Expressions

2018-04-17 Thread Glenn Linderman
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

Re: [Python-Dev] PEP 572: Assignment Expressions

2018-04-17 Thread Jeroen Demeyer
On 2018-04-18 02:13, Chris Angelico wrote: I'm much happier promoting a full-featured assignment expression than something that can only be used in a limited set of situations. Is there reason to believe that extensions to the := operator might take it in a different direction? If not, there's

Re: [Python-Dev] PEP 572: Assignment Expressions

2018-04-17 Thread Paul Moore
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

Re: [Python-Dev] Basic test to validate win10 install?

2018-04-17 Thread Terry Reedy
On 4/16/2018 6:00 PM, Martin Gainty wrote: I was told the python -m test are for devs only to test "auxiliary functions" People say all sorts of nonsense. I don't know what 'auxiliary function' would mean in this context. The Windows installer optionally installs the tests so that users

Re: [Python-Dev] PEP 572: Assignment Expressions

2018-04-17 Thread Chris Angelico
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

Re: [Python-Dev] PEP 572: Assignment Expressions

2018-04-17 Thread Tim Peters
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

Re: [Python-Dev] Basic test to validate win10 install?

2018-04-17 Thread Martin Gainty
Please feel free to reply to python-dev@python.org rather than me personally to take this back to the list. On Tue, Apr 17, 2018 at 1:20 PM, Martin Gainty wrote: > I'll need a few specifics before i wandering into "dll hell" > > .NetFramework version? > RT Library version?

[Python-Dev] https://bugs.python.org/issue33127 breaks pip / easy_install / pipenv etc in corporate networks on MS Windows using self-signed certificates

2018-04-17 Thread Oleg Sivokon
It is common practice in corporate networks that connect MS Windows machines to redirect all (encrypted included) traffic through company's router. For this purpose routers are usually configured to act as a CA. However, the certificate issued by such "CA" will of course not be found in the

Re: [Python-Dev] PEP 572: Assignment Expressions

2018-04-17 Thread Yury Selivanov
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

Re: [Python-Dev] PEP 572: Assignment Expressions

2018-04-17 Thread Paul Moore
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

Re: [Python-Dev] PEP 572: Assignment Expressions

2018-04-17 Thread Larry Hastings
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

Re: [Python-Dev] Translating sample programs in documentation

2018-04-17 Thread Xuan Wu
Hi Erik, thanks a lot for the support. As mentioned in the thread in Doc-Sig list, IMO it can be great showcase to use identifiers in native languages, which PEP 3131 was designed for initially, while even now many beginners don't even know it's possible. Besides, thanks to the references

Re: [Python-Dev] PEP 572: Assignment Expressions

2018-04-17 Thread Terry Reedy
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

Re: [Python-Dev] PEP 572: Assignment Expressions

2018-04-17 Thread Tim Peters
[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

Re: [Python-Dev] PEP 572: Assignment Expressions

2018-04-17 Thread Terry Reedy
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

Re: [Python-Dev] https://bugs.python.org/issue33127 breaks pip / easy_install / pipenv etc in corporate networks on MS Windows using self-signed certificates

2018-04-17 Thread Steve Dower
On 17Apr2018 0246, Oleg Sivokon wrote: It is common practice in corporate networks that connect MS Windows machines to redirect all (encrypted included) traffic through company's router. For this purpose routers are usually configured to act as a CA. However, the certificate issued by such

Re: [Python-Dev] PEP 572: Assignment Expressions

2018-04-17 Thread Eric Snow
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

Re: [Python-Dev] PEP 572: Assignment Expressions

2018-04-17 Thread Steven D'Aprano
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 >

Re: [Python-Dev] PEP 572: Assignment Expressions

2018-04-17 Thread Tim Peters
[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

Re: [Python-Dev] PEP 572: Assignment Expressions

2018-04-17 Thread Chris Angelico
On Wed, Apr 18, 2018 at 11:20 AM, Steven D'Aprano wrote: > 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

Re: [Python-Dev] PEP 572: Assignment Expressions

2018-04-17 Thread Rob Cliffe via Python-Dev
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

Re: [Python-Dev] PEP 572: Assignment Expressions

2018-04-17 Thread Chris Angelico
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

Re: [Python-Dev] PEP 572: Assignment Expressions

2018-04-17 Thread MRAB
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

Re: [Python-Dev] PEP 572: Assignment Expressions

2018-04-17 Thread Guido van Rossum
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.

Re: [Python-Dev] PEP 572: Assignment Expressions

2018-04-17 Thread Eric Fahlgren
On Tue, Apr 17, 2018 at 6:20 PM, Steven D'Aprano wrote: > If there are tests which intentionally verify this behaviour, that > really hurts your position that the behaviour is an accident of > implementation. It sounds like the behaviour is intended and required. > ​It is

Re: [Python-Dev] PEP 572: Assignment Expressions

2018-04-17 Thread Greg Ewing
Paul Moore wrote: the next question will likely be "so why does = exist at all?" And if we decide to make ':=' the official assigment operator and deprectate '=', the next question will be "Why do we have '==' instead of '='?" -- Greg ___

Re: [Python-Dev] PEP 572: Assignment Expressions

2018-04-17 Thread Tim Peters
[Paul Moore] >> the next question will likely be "so why does = exist at all?" [Greg Ewing ] > And if we decide to make ':=' the official assigment operator and > deprectate '=', the next question will be "Why do we have '==' > instead of '='?" Which would be a fine