"Structural pattern matching" for Python, part 2 [LWN.net]

"Structural pattern matching" for Python, part 2

Posted Sep 1, 2020 17:57 UTC (Tue) by martin.pitt (subscriber, #26246)
Parent article: "Structural pattern matching" for Python, part 2

I find Mark Shannon's analysis very compelling. Even though I just looked at the examples (not the discussion), these are the ones that the proponents picked - so I'd expect them to be prime candidates for match. If even these are so riddled with ambiguities and subtle bugs, then IRL code will hardly get better. There is such a thing for changing the language for change's sake!

to post comments

"Structural pattern matching" for Python, part 2

Posted Sep 1, 2020 19:25 UTC (Tue) by logang (subscriber, #127618) [Link] (5 responses)

I agree. Though, it seems more like they are changing the language just to add a feature other languages have without considering whether it's good for python or even a good feature at all.

I personally find the syntax incredibly confusing and overly magic in any language -- so many rust examples that I've seen just leave me scratching my head.

"Structural pattern matching" for Python, part 2

Posted Sep 2, 2020 2:38 UTC (Wed) by atnot (guest, #124910) [Link] (3 responses)

This is my problem with this feature. I love rust's pattern matching, but what really makes that useful is the rest of the language, most notably tagged unions or as rust calls them enums. Python has none of those features. If python were to have those, which I would love, I think match could be incredibly useful, but it doesn't.

"Structural pattern matching" for Python, part 2

Posted Sep 2, 2020 6:01 UTC (Wed) by NYKevin (subscriber, #129325) [Link] (2 responses)

> most notably tagged unions or as rust calls them enums.

Perhaps the phrase "tagged unions" means something different to people who write Rust, but to my mind, PyObject* is a tagged union (and thus, so is every Python object). Am I misinterpreting you?

"Structural pattern matching" for Python, part 2

Posted Sep 2, 2020 7:24 UTC (Wed) by ehiggs (subscriber, #90713) [Link] (1 responses)

You are correct that a PyObject is a tagged union. The point here, however, is that match in Rust is exhaustive. You must write the match case for every possible branch if you want your Rust code to compile. Making match on PyObject exhaustive would mean you need a branch covering all possible types.

Since so many things can be a PyObject, this isn't feasible unless you just had a fallthrough case (in Rust this uses _). The problem then is that you will never catch bugs when extending the code because you will happily use the fall through case when a new field in the enum is added.

"Structural pattern matching" for Python, part 2

Posted Sep 13, 2020 11:11 UTC (Sun) by plugwash (subscriber, #29694) [Link]

> You are correct that a PyObject is a tagged union.

I would argue it's more akin to a base class than to a tagged union with the "ob_type" field serving a role similiar to a vptr.

To me at least "tagged union" implies that the list of subtypes is determined in advance and sufficient memory is allocated to store any of the subtypes.

"Structural pattern matching" for Python, part 2

Posted Sep 3, 2020 16:38 UTC (Thu) by jcpunk (subscriber, #95796) [Link]

I agree. I've yet to be convinced this is actually any better than

if XXX:
  print(x)
elseif YYY:
  print(y)
elseif ZZZ:
  print(z)
else:
  raise ValueError()