On 2018-04-24 02:21, Victor Stinner wrote:

I have been asked to express myself on the PEP 572. I'm not sure that

Thanks. Well written and I've had the same thoughts myself.

On Tue, Apr 24, 2018 at 2:21 AM, Victor Stinner wrote:

== Write code for babies! ==

Please don't write code for yourself, but write code for babies! :-) These babies are going to maintain your code for the next 5 years, while you moved to a different team or project in the meanwhile. Be kind with your coworkers and juniors!

I don't like the idea of assignment expressions in Python. “Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” - Brian Kernighan Of the proposed syntaxes, I dislike identifer := expression less, but I'd still rather not see it added.

On Tue, Apr 24, 2018 at 2:21 AM, Victor Stinner wrote:

Even if the C language allows assignments in if, I avoid them, because I regularly have to debug my own code in gdb ;-)

I personally haven't written a lot of C, so have no personal experience, but if this is at all a common approach among experienced C developers, it tells us a lot. We shouldn't add a feature that people would make a point of avoiding! OT note:

Now the question is which Python are allowed for babies. I recall that a colleague was surprised and confused by context managers. Does it mean that try/finally should be preferred?

well, no, because try ... finally is even more confusing -- at least that's the impression I get from spending 20 minutes on it with newbies in my class last night :-)

Or metaclasses?

metaclasses are well known to be advanced juju -- they should not (and probably don't) show up in everyday code. Even if they are used in everyday code, the use is usually hidden -- i.e. when a user subclasses from an ORM model class, they are using metaclasses, but they don't have to know that. That is -- they fall into the category of stuff that should only be used by library/framework developers -- and, in fact, the whole point is to make everyday code easier. In fact, the number of developers that need to write/debug metaclasses, context managers, decorators, is far fewer than the number of folks that USE those things. So the standards are very different. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov

2018-04-28 17:45 GMT+02:00 Antoine Pitrou :

// Read up to n bytes from file descriptor if ((bytes_read = read(fd, buf, n)) == -1) { // Error occurred while reading, do something }

About C, there is a popular coding style (not used by our PEP 7) for comparison: if (-1 == n) ... The advantage is to prevent typo mistakes because "-1 = n" is a syntax error. Victor

[Raymond Hettinger ]

Thanks Antoine, this is an important point that I hope doesn't get lost. In a language with exceptions, assignment expressions are less needful. Also, the pattern of having of having mutating methods return None further limits the utility.

It doesn't diminish the utility one whit in cases where binding expressions are helpful ;-) What you're saying is that there are _fewer_ such opportunities in Python than in C. Which may or may not be true (depending on the code you're working with). If you believe it is true, fine, then that also argues against that people will rush to abuse the feature (to the extent that it's even plausibly useful less often, to that extent also will there be less temptation to use it at all). But then I only care about use cases at heart, and have presented real-life examples wherein binding expressions read both better and worse than what they're replacing. I intend to limit myself to the cases where they read better :-) Which are most of the cases I even considered, BTW - in the vast majority of cases in real code I'd use them, they'd be replacing the annoyingly bare-bones yet somehow repetitive anyway: value = f() if value; doing something with value with the still bare-bones but minimally repetitive: if value := f(): doing something with value For example, tons of functions I write and use return None or 0 or False when they want to communicate "I have nothing useful to return in this case - but since you expected that might happen, I'm not going to annoy you with an exception". That pattern isn't solely limited to regexp search and match functions. The "win" above is minor but frequent. It adds up. There are other cases where binding expressions really shine, but they're much rarer in all the code I looked at (e.g., see the uselessly ever-increasing indentation levels near the end of `copy()` in the std library's copy.py). In all, I expect I'd use them significantly more often than ternary `if`, but far less often than augmented assignments. If the PEP is accepted, that's what all Pythoneers will be saying 5 years from now ;-)

On Wed, Jul 04, 2018 at 03:21:29PM +0400, Abdur-Rahmaan Janhangeer wrote:

was going to tell

instead of := maybe => better

:= too close to other langs

The fact that := will be familiar to many people (especially if they know Go, Pascal or Eiffel etc) is a point in its favour. https://en.wikipedia.org/wiki/Assignment_%28computer_science%29#Notation The => arrow puts the arguments around the "wrong" way compared to regular assignment: name = expression expression => name Although personally I like that order, many people did not and I think Guido ruled it out very early in the discussion. Also it may be too easily confused with <= or >= or the -> syntax from annotations. -- Steve

The PEP 572 has been approved, it's no longer worth it to discuss it ;-) Victor 2018-07-04 13:21 GMT+02:00 Abdur-Rahmaan Janhangeer :

was going to tell

instead of := maybe => better

:= too close to other langs

Abdur-Rahmaan Janhangeer https://github.com/Abdur-rahmaanJ

...

Of the proposed syntaxes, I dislike identifer := expression less, but

I'd still rather not see it added. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/arj.python%40gmail.com

On Wed, Jul 04, 2018 at 03:36:18PM +0300, Ivan Pozdeev via Python-Dev wrote:

On 04.07.2018 15:29, Victor Stinner wrote:

...

The PEP 572 has been approved, it's no longer worth it to discuss it ;-)

Victor

As of now, https://www.python.org/dev/peps/pep-0572/ is marked as "draft".

https://mail.python.org/pipermail/python-dev/2018-July/154231.html https://mail.python.org/pipermail/python-dev/2018-July/154247.html The state of the published PEP has unfortunately lagged behind the state of the discussion, due to the overwhelming number of posts. -- Steve