"Structural pattern matching" for Python, part 2

Posted Sep 2, 2020 2:38 UTC (Wed) by atnot (subscriber, #124910)
In reply to: "Structural pattern matching" for Python, part 2 by logang
Parent article: "Structural pattern matching" for Python, part 2

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.