[uryga]

glad to see this! though it's a shame that the proposed `match/case` is a statement, not an expression:

> "We propose the match syntax to be a statement, not an expression. Although in many languages it is an expression, being a statement better suits the general logic of Python syntax."

no matching in lambdas unless those get overhauled too :(

instead, let's get excited for a whole bunch of this:

  match x
    case A:
      result = 'foo'
    case B:
      result = 'bar'

(i guess i'm a little salty...)

[rattray]

Yeah, came here to say the same thing. Disappointing to have to write this:

    match shape:
        case Square(l):
            area = l * l
        case Rectangle(l, w):
            area = l * w
        case Circle(r):
            area = (PI * r) ** 2

when I want to just write this:

    area = match shape:
        case Square(l):
            l * l
        case Rectangle(l, w):
            l * w
        case Circle(r):
            (PI * r) ** 2

I'm almost guaranteed to forget (or mistype) the `area = ` at least once in any match clause of length.

[whalesalad]

That works almost exactly in Ruby. I really wish Python and Ruby would have a child.

[rattray]

Funny. Having worked extensively with Ruby and less so with Python, I think what I really want is expression-oriented Python.

Ideally as a next version of Python. But I think Julia and Nim come to mind as related to these concepts.

[BiteCode_dev]

> 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.

[uryga]

what do you think about if-expressions?

  x if cond else y

IMO match-expressions have basically the same benefits/trade-offs.

[BiteCode_dev]

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.

[uryga]

> 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.

[heavenlyblue]

Ternary expressions are not covered by python code coverage tools by the way.

[uryga]

interesting! why not?

[j88439h84]

Bytecode tracing is new in 3.7, and nobody's used it in coverage.py yet.

[yowlingcat]

I wonder if this is intentional. FP constructs are increasingly discouraged in Python, taking reduce [1] as an example. Not that this is necessarily a bad thing, per sé -- I think it does simplify the language. But it's an opinionated decision that will discourage FP enthusiasm from finding a home in Python.

[1] http://lambda-the-ultimate.org/node/587

[dragonwriter]

> I wonder if this is intentional. FP constructs are increasingly discouraged in Python, taking reduce [1] as an example.

That single comment from Guido 15 years ago, which was largely backtracked on—map and filter remain in the core library and reduce moved to a library in stdlib, lambda remains—is not really an example of something accurately described as “increasingly” now. In fact, given the backtracking, it's arguably decreasingly true from the high point of that post.

[pjmlp]

With a good mix of comprehensions, itertools, functools and lambda, there is enough stuff to get creative with FP in Python anyway.

[uryga]

btw, my favorite FP-hack: let-in expressions with lambdas OR list comprehensions:

  let x = foo in expr

can be

  [expr for x in (foo,)][0]

(kinda reads like a Haskell `where` clause!) or:

  (lambda x = foo: expr)()

useful in a pre-walrus-operator REPL :)

[heavenlyblue]

If you want to program in Haskell, why don’t you get a job programming in Haskell rather than inventing something so ugly?

You would not get through code review with that in any shop that has discipline.

[uryga]

> You would not get through code review with that in any shop that has discipline.

... and i'd never think to try! that's why i mentioned using it in a REPL and called it a hack :) it's just fun. i played around with bytecode-rewriting too, doesn't mean i'd use it in production.

PS. for a less extreme version, the 1-elem-tuple trick is useful if you need an intermediate variable in a listcomp:

  [
    y+y
    for x in my_list
    for y in (foo(x),)
  ]

but it's (obviously) ugly & only useful if you're in a REPL and don't want to rewrite the whole thing.

[andybak]

Yeah but constantly jumping between idioms means this is stuff I have to usually look up instead of just intuiting.

[uryga]

the Syntax section has a bit more:

> "[...] making it an expression would be inconsistent with other syntactic choices in Python. All decision making logic is expressed almost exclusively in statements, so we decided to not deviate from this."

so it's just keeping in line with Python's general imperativess.

> FP constructs are increasingly discouraged in Python [...] Not that this is necessarily a bad thing, per sé

i, on the other hand, do think it's a bad thing :) but what can you do...

[adamnew123456]

> i, on the other hand, do think it's a bad thing :) but what can you do...

Hy[1] I guess? It looks pretty lively although I'm not sure how seriously people take it these days.

[1]: https://github.com/hylang/hy

[goto11]

Not sure about "increasingly" - note the comment you link to is 15 years old! It seems more like a recognition that map/filter/reduce never was idiomatic Python and there are better ways to do the same. Python have never tried to be a functional language.

[mdrachuk]

BDFL made good points though.

[dragonwriter]

Just as named functions replace multiline lambdas, I expect that named matcher functions (functions that consist entirely of a match where each arm is a return) will replace match expressions in python.

Abstractly, I'd rather have match expressions, too, but this does fit the rest of Python better.

[uryga]

it's a shame :( and honestly, i think the whole "if it needs statements, it should be a named function anyway" argument is misguided (and maybe kind of a post-hoc justification of the limitations of Python lambdas). introducing a named function for something that's only going to be used in one place messes up the order (you have to keep the function in your head until it gets used) thus often making the code harder to read.