Hacker News new | ask | show | jobs
by BiteCode_dev 2180 days ago
> glad to see this! though it's a shame that the proposed `match/case` is a statement, not an expression:

> no matching in lambdas unless those get overhauled too :(

Hate it or like it, but it's congruent with the rest of Python design.

Guido has been hostile with introducing too much FP in Python.

While I find it frustrating from time to time, espacially when I come back from another language to Python, on the long run, I must say I understand.

I don't like to work with FP languages, because unless your team is really good, the code ends up hard to read and debug. It's possible to make very beautiful code in FP, but it makes it so easy to create huge chains of abstract things.

And devs are not reasonable creatures. Give them a gun with 6 bullets, they'll shoot them all, and throw some stones once it's empty.

To me, the average dev is not responsible enought with code quality, and should not be trusted. I'm all for tooling enforcing as much as you can. Linters and formatters help a lot. But sometimes, language design limiting them is a god send.

I've seen the result with Python: you can put a math teacher, a biologist and frontend dev on their first backend project, and they will make something I can stand reading.

1 comments

what do you think about if-expressions?

  x if cond else y
IMO match-expressions have basically the same benefits/trade-offs.
Match are usually much more complex than a single ternary condition. Allow to inline them and you will see monsters in the wild.

But I do wish they would have not set aside generalized unpacking.

> Allow to inline them and you will see monsters in the wild.

idk... you can write a huge ugly if-elif-else like this:

  a if foo else b if bar else c if quux else d
but most people just don't.
Ternary expressions are not covered by python code coverage tools by the way.
interesting! why not?
Bytecode tracing is new in 3.7, and nobody's used it in coverage.py yet.