PEP 572: Write vs. Read, Understand and Control Flow
mail.python.org
PEP 572: Write vs. Read, Understand and Control Flow
1–10 of 28 posts
Re: PEP 572: Write vs. Read, Understand and Control Flow
#2At least it introduces a new operator, to avoid the classic C mistake of typing "=" when you meant "==", and various ugly workarounds like Yoda conditions.
This would be a huge boon for many list/dict/set comprehensions, as currently there's no way to filter on the result of a function call in the same comprehension (map + filter in one):
results = [b for b in input_data if (b := f(a))]
Re: PEP 572: Write vs. Read, Understand and Control Flow
#3At least it introduces a new operator, to avoid the classic C mistake of typing "=" when you meant "==", and various ugly workarounds like Yoda conditions. This would be a huge boon for many list/dict/set comprehensions, as currently there's no way to filter on the result of a function call in the same comprehension (map + filter in one): results = [b for b in input_data if (b := f(a))] I think it's slightly unpython…
That's a better use case, but this just seems like something that's adding complexity to the language for little gain. Writing a generator to do the more complex thing is probably a much better (and more readable) alternative, if a list comprehension isn't cutting it.
Re: PEP 572: Write vs. Read, Understand and Control Flow
#4As a long-time Python user, this is one of the worst proposals I've seen.
Yes, it has a potential for being useful.
But its usefulness, unlike context managers and async, is very limited, implied a substantial cognitive overhead by introducing a new operator, and has a very significant potential for abuse.
One of the nice things about Python is that it is highly succing while disallowing the sort of expressions that are too information-dense to be easily understood, which has been a critique of mine in other languages of similar use cases (Clojure, Haskell, I'm looking at you).
Succinctness is good if it allows expressing ideas in a way that maximize comprehensibility and go straight to the point.
But truth is, nobody's missing out on serious functionality by not being able to do an assignment on the same line of code as a conditional. It can be very slightly annoying, possibly. But I look at the examples and I'm really not convinced that this feature is so orthogonal and useful as to merit inclusion.
It feels like accepted PEPs are slowly coming under less scrutiny and disregarding the idea of feature orthogonality and low overhead.
Re: PEP 572: Write vs. Read, Understand and Control Flow
#5At least it introduces a new operator, to avoid the classic C mistake of typing "=" when you meant "==", and various ugly workarounds like Yoda conditions. This would be a huge boon for many list/dict/set comprehensions, as currently there's no way to filter on the result of a function call in the same comprehension (map + filter in one): results = [b for b in input_data if (b := f(a))] I think it's slightly unpython…
> `results = [b for b in input_data...`
Did you mean `[b for a in...`?
Re: PEP 572: Write vs. Read, Understand and Control Flow
#6What I love about Python is that it has a limited set of "symbols" I had to learn. I would have for new cryptic combinations of characters to arise with some kind of meaning.
> The LONG version looks like your expressiveness is limited by the computer. It's like having to use simple words when you talk to a child, because a child is unable to understand more subtle and advanced sentences.
Fantastic! Easy to understand code is what makes Python so great.
Re: PEP 572: Write vs. Read, Understand and Control Flow
#7Wow. I would love to see this become real. There are so many cases where I want to be able to use assignment as an expression like in lisp and it is simply not possible in python because of how locals works. This would (hopefully?) finally make it possible to assign names dynamically in python which is a feature that is sorely missing and leads to enormous amounts of code duplication where sometimes you have to write the same variable 3 times when you should only have to write it twice (the if statement example is exactly this). f-strings solved some of those issues, this looks like could solve some of the others.
Re: PEP 572: Write vs. Read, Understand and Control Flow
#8As a long-time Python user, this is one of the worst proposals I've seen. Yes, it has a potential for being useful. But its usefulness, unlike context managers and async, is very limited, implied a substantial cognitive overhead by introducing a new operator, and has a very significant potential for abuse. One of the nice things about Python is that it is highly succing while disallowing the sort of expressions that…
It isn't an accepted PEP, just a draft.
Re: PEP 572: Write vs. Read, Understand and Control Flow
#9I find the short example a strange choice. Sure, you can build a crazy expression which is hard to process / read / debug. But the change also enables this, which solves most problems raised and makes reading easier:
if diff := x - x_base:
if (g := gcd(diff, n)) > 1:
return g
if diff := x - x_base:
g = gcd(diff, n)
if g > 1:
return gRe: PEP 572: Write vs. Read, Understand and Control Flow
#10This proposal looks on the surface to be useful but the more I think about it, the feature look like it would be awful for those of us who try to write side-effect-free code whenever possible. The assignments made here leak their references to all following statements, making it much harder to track the actual ramifications of any of these assignments.
I'd say this is in stark contrast to PEP 3150 which tries to solve similar problems but does so by introducing functional let-style statement-local assignments, retaining an amount of "encapsulation" of expressions and their sub-expressions.
> You can see it as a limitation of pdb, but many tools only have the granularity of whole line
As somebody who likes to write quite "functional" code, I do see this as a significant limitation. But it's one that I'd really like to see addressed rather than used to restrict our ability to express our intentions in succinct ways.
> write code for babies!
I strongly disagree with this notion. Professional developers are supposed to be professionals, as in, people whose (paid!) job is to write code full-time. It's a discouraging trend to be principally structuring your engineering project around the abilities of (full-time!) coders who can often had rings run around them by amateurs. Code written "for babies" (presumably omitting language features because some may not know them) tends to turn into a long winded mess all too quickly.
How are babies ever supposed to learn to be anything else if all they ever see is baby code?
> I'm trying to write a single instruction per line whenever possible
I'm glad he phrased it like this, because I find reading code written like this uncannily like reading assembly.