"Structural pattern matching" for Python, part 2

Posted Sep 9, 2020 13:37 UTC (Wed) by milesrout (subscriber, #126894)
In reply to: "Structural pattern matching" for Python, part 2 by kleptog
Parent article: "Structural pattern matching" for Python, part 2

At that point, how is this better than


(x, y) = size
if x == y:
    circle()
else:
    ellipse()

I would contend that it is not. It is an extra level of indentation and a whole new complicated language construct.

"Structural pattern matching" for Python, part 2

Posted Sep 9, 2020 22:16 UTC (Wed) by johill (subscriber, #25196) [Link] (6 responses)

Your version crashes if you pass it a 3-tuple or something else.

The match/case version can handle such things without you having to put another "is a 2-tuple" if outside of it.

"Structural pattern matching" for Python, part 2

Posted Sep 10, 2020 2:12 UTC (Thu) by milesrout (subscriber, #126894) [Link] (5 responses)

That's quite intentional. If you are passing the wrong type of value to a function then your code should crash. The code will also crash if I pass a string to a function that expects an integer. Code should not be full of defensive checks for programmer error: they're code paths that are hard if not impossible to test and by design are intended to never be run (nobody makes programmer errors on purpose). Type checks are for dispatching based on type in Python, and most of the time 'isinstance' checks are the wrong way of doing things. "if isinstance elif isinstance elif isinstance"-style code is considered unPythonic, and I don't think that papering over that code with a language construct makes it a good idea.

Now there are possibly some cases where you want to be able to pass different sizes of tuples to a single function. However I think in most of those cases you probably shouldn't be using tuples, you should be using something like a named tuple, a dictionary, a custom class, a dataclass with an optional field, or just separate arguments to a single function, some of which are optional.

Or possibly you should actually be making a decision 'am I working with 2-tuples or 3-tuples?' at a higher level and switch. If you had some code that is meant to work with 2D or 3D or 4D vectors for example, it would be better to have separate functions for the length of 2D, 3D and 4D vectors than a single function that does


    def veclen(v):
      match v:
        case (x,y): return sqrt(x*x + y*y)
        case (x,y,z): return sqrt(x*x + y*y + z*z)
        case (x,y,z,w): return sqrt(x*x + y*y + z*z + w*w)

Then you should make the determination as to whether you are working with 2D, 3D or 4D vectors at a high level and write all the functions dealing with 2D, 3D or 4D vectors separately.

For example if you really want to write 'length-agnostic' code with tuples up to some maximum length, then you should encapsulate that variation in size in Vector2D, Vector3D and Vector4D etc. classes with a common Vector superclass such that Vector's methods can be those that are parametric in the dimension.

And if it's really truly length-agnostic tuple code then you should be writing loops over lists, not matching on tuples.

"Structural pattern matching" for Python, part 2

Posted Sep 11, 2020 6:29 UTC (Fri) by johill (subscriber, #25196) [Link] (4 responses)

Well, that's a question of your architecture/design, but a large part of the whole point of the match statement was to be able to match different types in the same place.

"Structural pattern matching" for Python, part 2

Posted Sep 11, 2020 12:53 UTC (Fri) by milesrout (subscriber, #126894) [Link] (3 responses)

And what I am saying, quite clearly I think, is that I do not think that that is the right thing to be doing in Python code. It's not supported by the language *for good reason*.

"Structural pattern matching" for Python, part 2

Posted Sep 11, 2020 13:27 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (2 responses)

> It's not supported by the language *for good reason*.

This feels like one of those "cannot derive ought from is" statements. Is there any indication that something better than `isinstance` if-trees was explicitly rejected earlier in the language's design process? I'd expect the previous approach was "just treat it like a duck and if it quacks well enough, what do you care?", but with types now becoming more and more of a thing in general (even in Python), this seems like a natural thing to be considering around this time (to me at least).

"Structural pattern matching" for Python, part 2

Posted Sep 12, 2020 4:30 UTC (Sat) by milesrout (subscriber, #126894) [Link] (1 responses)

>Is there any indication that something better than `isinstance` if-trees was explicitly rejected earlier in the language's design process?

Yes. Switch statement suggestions have been rejected over and over again. Pattern matching proposals have been rejected before. 'if isinstance' isn't considered bad Python because it's *ugly* but because it's *bad design*. Dispatching on types is just not a good way to write code in a dynamically typed language. There is no - and can be no - exhaustiveness checking for example, to give just one example of why it's a problem.

>but with types now becoming more and more of a thing in general (even in Python), this seems like a natural thing to be considering around this time (to me at least).

Adding type annotations to Python is yet another example of the continual application of bad ideas to clutter up Python, done by people trying to roleplay as Haskell programmers. Pattern matching is the same thing. It's blatant cargo culting.

"Structural pattern matching" for Python, part 2

Posted Sep 16, 2020 16:02 UTC (Wed) by HelloWorld (guest, #56129) [Link]

> Dispatching on types is just not a good way to write code in a dynamically typed language. There is no - and can be no - exhaustiveness checking for example, to give just one example of why it's a problem.

That problem has nothing to do with pattern matching and everything to do with dynamic typing, which is quite simply an inherently bad idea.