Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PEP 572: Write vs. Read, Understand and Control Flow

mail.python.org

Post reply on HN
Print view View original

11–20 of 28 posts

Re: PEP 572: Write vs. Read, Understand and Control Flow

#11

Post by ris »

guitarbill wrote: post #2

At 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…

This case could also be addressed by something more like PEP 3150 without the nasty potential for leaking the scope of an assignment beyond that statement in a non-obvious way.

https://www.python.org/dev/peps/pep-3150/

Re: PEP 572: Write vs. Read, Understand and Control Flow

#12

Post by orangecat »

aw3c2 wrote: post #6

What 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 understan…

Easy to understand code is what makes Python so great.

"Easy to understand" doesn't mean "every individual statement should be as simple as possible". Otherwise we'd be using assembly for everything.

Re: PEP 572: Write vs. Read, Understand and Control Flow

#13

Post by kbob »

guitarbill wrote: post #2

At 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…

It's an open question whether that's more readable than the already legal

    results = [b for b in (f(a) for a in input_data) if b]

Re: PEP 572: Write vs. Read, Understand and Control Flow

#14

Post by abecedarius »

repsilat wrote: post #5
guitarbill wrote: post #2

At 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...`?

Assuming so, there’s [result for a in input_data for result in [f(a)] if result] if you’ve just gotta make it a comprehension.

Re: PEP 572: Write vs. Read, Understand and Control Flow

#15

Post by theptip »

I'm not particularly sold on this proposal, but the examples in the OP seem like poor counterarguments; there are a lot of ways to write incomprehensible python. (Nested list comprehensions anyone?)

And it's already possible to write one-liners that do too many things; I'm not convinced that this proposal would make that worse.

Best to consider how this feature would actually be used, and make a judgement as to whether the value outweighs the cost of making the language more complicated and harder to learn.

This proposal does have some benefits - this is the best use-case I can think of:

Instead of

  response = do_thing()
  while response != 200:
    handle_error(response)
    response = do_thing()
(Which in many other languages would be a do-while)

Instead we could write:

  while (response := do_thing()) != 200:
    handle_error(response)
That doesn't seem like a big improvement though...

Re: PEP 572: Write vs. Read, Understand and Control Flow

#16

Post by fnulnu »

Daishiman wrote: post #4

As 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…

Whilst I personally prefer succinct code, the proposal looks to be unpythonic. Why is this any better than ‘—i’? Arguably the same thing could be said for list & map comprehension.

Re: PEP 572: Write vs. Read, Understand and Control Flow

#17

Post by aw3c2 »

orangecat wrote: post #12
aw3c2 wrote: post #6

What 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 understan…

Easy to understand code is what makes Python so great. "Easy to understand" doesn't mean "every individual statement should be as simple as possible". Otherwise we'd be using assembly for everything.

I think we agree? I want readable, not simple/small.

Re: PEP 572: Write vs. Read, Understand and Control Flow

#18

Post by talltimtom »

As a long time Python programmer and even longer time Wolfram Lang/Mathematica programmer, I just look at this and think “yea, that’s exactly how I thought assignment worked When I started learning Python”

I mean what else than the assigned value would you expect an assignment to return? Naturally Python assignment is a special concept, but in Mathematica assignment is just a function. So it seems more natural in Mathematica. I wouldn’t mind this, however it does seem like Python deliberately tries to be less functional, hiding away map/apply and such elements and recommending lay comprehensions, so it might just not fit with Python as it is now.

Re: PEP 572: Write vs. Read, Understand and Control Flow

#20

Post by coldtea »

theptip wrote: post #15

I'm not particularly sold on this proposal, but the examples in the OP seem like poor counterarguments; there are a lot of ways to write incomprehensible python. (Nested list comprehensions anyone?) And it's already possible to write one-liners that do too many things; I'm not convinced that this proposal would make that worse. Best to consider how this feature would actually be used, and make a judgement as to wheth…

Looks like a major improvement in readability to me...
Post reply on HN