Arguments Against Python Pattern Matching<\/h2>\n\n\n\nSignificant Gotchas<\/h3>\n\n\n\n
This section includes some material from the previous blog post but with a different emphasis and more detail.<\/p>\n\n\n\n
Similarity to object instantiation misleading<\/em><\/h4>\n\n\n\nImagine we have a Point class:<\/p>\n\n\n\n
class Point:
def __init__(self, x, y):
pass<\/code><\/p>\n\n\n\n
case Point(x, y):<\/code> seems to me to be an obvious way of looking for such a Point<\/code> object and unpacking its values into x<\/code> and y<\/code> but it isn\u2019t allowed. It is a perfectly valid syntax for instantiating a Point<\/code> object but we are not instantiating an object and supplying the object the case condition \u2013 instead we are supplying a pattern to be matched and unpacked. We have to have a firm grasp on the notion that Python patterns are not objects. If we forget we get a TypeError:<\/p>\n\n\n\ncase Point(0, 999):
TypeError: Point() accepts 0 positional sub-patterns (2 given)<\/code><\/p>\n\n\n\nNote, we must match the parameter names (the left side) but can unpack to any variable names we like (the right side). For example, all of the following will work:<\/p>\n\n\n\n
case Point(x=x, y=y):
case Point(x=lon, y=lat):<\/code>
case Point(x=apple, y=banana):<\/code><\/p>\n\n\n\nbut<\/p>\n\n\n\n
case Point(a=x, b=y):<\/code><\/p>\n\n\n\nwill not.<\/p>\n\n\n\n
It is a bit disconcerting being forced to use what feel like keyword arguments in our patterns when the original class definition is optionally positional. We should expect lots of mistakes here and it’ll require concentration to pick them up in code review.<\/p>\n\n\n\n
Similarity to isinstance misleading<\/em><\/h4>\n\n\n\ncase Point:<\/code>, case int:<\/code>, case str:<\/code>, case float:<\/code> don\u2019t work as you might expect. The proper approach is to supply parentheses: using the example of integer patterns, we need case int():<\/code>, or, if we want to \u201ccapture\u201d the value into, say, x<\/code>, case int(x):<\/code>. But if we don’t know about the need for parentheses, or we slip up (easy to do) these inadvertant patterns will match anything and assign it to the name Point<\/code> or int<\/code> or str<\/code> etc. Definitely NOT what we want.<\/p>\n\n\n\n![\"\"](\"http:\/\/p-s.co.nz\/wordpress\/wp-content\/uploads\/2021\/03\/str_overwritten.png\")
<\/a>the builtin str is now broken – hopefully obviously<\/figcaption><\/figure>\n\n\n\nThe only protection against making this mistake is when you accidentally do this before other case conditions \u2013 e.g.<\/p>\n\n\n\n
case int:
^
SyntaxError: name capture 'int' makes remaining patterns unreachable<\/code><\/p>\n\n\n\nOtherwise you’re on your own and completely free to make broken code. This will probably be a common error because of our experience with isinstance<\/code> where we supply the type e.g. isinstance(x, int)<\/code>. Which reminds me of a passage in Through the Looking-Glass, and What Alice Found There<\/em> by Lewis Carroll.<\/p>\n\n\n\n‘Crawling at your feet,’ said the Gnat (Alice drew her feet back in some alarm), ‘you may observe a Bread-and-Butterfly. Its wings are thin slices of Bread-and-butter, its body is a crust, and its head is a lump of sugar.’<\/p><\/blockquote>\n\n\n\n
‘And what does it<\/strong> live on?’<\/p>‘Weak tea with cream in it.’<\/p>
A new difficulty came into Alice’s head. ‘Supposing it couldn’t find any?’ she suggested.<\/p>
‘Then it would die, of course.’<\/p>
‘But that must happen very often,’ Alice remarked thoughtfully.<\/p>
‘It always happens,’ said the Gnat. After this, Alice was silent for a minute or two, pondering.<\/p><\/blockquote>\n\n\n\n
Summary<\/h3>\n\n\n\n
There will be lots of mistakes when using the match case even in the most common cases. And more complex usage is not readable without learning a lot more about Pattern Matching. See PEP 622<\/a>.<\/p>\n\n\n\n![\"\"](\"http:\/\/p-s.co.nz\/wordpress\/wp-content\/uploads\/2021\/03\/match_case_mini_language.png\")
<\/a>Readable but only if you understand the mini-language<\/figcaption><\/figure>\n\n\n\nBasically it is a yet another mini-language to learn.<\/p>\n\n\n\n
Arguments for Python Pattern Matching<\/h2>\n\n\n\n
Sometimes we need to pattern match and a match \/ case syntax is quite elegant. The way values are unpacked into names is also really nice.<\/p>\n\n\n\n
We will certainly love this feature if we are moving away from duck typing and adopting the programming style of statically-typed languages like Scala. But maybe we shouldn’t encourage this style of programming by making it easier to write in Python.<\/p>\n\n\n\n
Verdict<\/h2>\n\n\n\n
In balance, Python Pattern Matching doesn’t seem to pass the Must-Be-Really-Valuable-To-Justify-the-Increased-Complexity test. And I’m not alone in wondering this (Musings on Python’s Pattern Matching<\/a>). I enjoyed coming to grips with the syntax but I think it is like for else<\/code> and Python Enums – best avoided. But we will see. We can’t always tell what the future of a feature will be – maybe it will turn out to be very useful and one day there will be a third blog post ;-).<\/p>\n","protected":false},"excerpt":{"rendered":"Less is More One of the beautiful things about Python is its simplicity. We don’t want it to end up like those languages which have a designed-by-committee feel where everyone gets to add features and there are many ways of … Continue reading
class Point:
def __init__(self, x, y):
pass<\/code><\/p>\n\n\n\n
case Point(x, y):<\/code> seems to me to be an obvious way of looking for such a Point<\/code> object and unpacking its values into x<\/code> and y<\/code> but it isn\u2019t allowed. It is a perfectly valid syntax for instantiating a Point<\/code> object but we are not instantiating an object and supplying the object the case condition \u2013 instead we are supplying a pattern to be matched and unpacked. We have to have a firm grasp on the notion that Python patterns are not objects. If we forget we get a TypeError:<\/p>\n\n\n\ncase Point(0, 999):
TypeError: Point() accepts 0 positional sub-patterns (2 given)<\/code><\/p>\n\n\n\nNote, we must match the parameter names (the left side) but can unpack to any variable names we like (the right side). For example, all of the following will work:<\/p>\n\n\n\n
case Point(x=x, y=y):
case Point(x=lon, y=lat):<\/code>
case Point(x=apple, y=banana):<\/code><\/p>\n\n\n\nbut<\/p>\n\n\n\n
case Point(a=x, b=y):<\/code><\/p>\n\n\n\nwill not.<\/p>\n\n\n\n
It is a bit disconcerting being forced to use what feel like keyword arguments in our patterns when the original class definition is optionally positional. We should expect lots of mistakes here and it’ll require concentration to pick them up in code review.<\/p>\n\n\n\n
Similarity to isinstance misleading<\/em><\/h4>\n\n\n\ncase Point:<\/code>, case int:<\/code>, case str:<\/code>, case float:<\/code> don\u2019t work as you might expect. The proper approach is to supply parentheses: using the example of integer patterns, we need case int():<\/code>, or, if we want to \u201ccapture\u201d the value into, say, x<\/code>, case int(x):<\/code>. But if we don’t know about the need for parentheses, or we slip up (easy to do) these inadvertant patterns will match anything and assign it to the name Point<\/code> or int<\/code> or str<\/code> etc. Definitely NOT what we want.<\/p>\n\n\n\n<\/a>the builtin str is now broken – hopefully obviously<\/figcaption><\/figure>\n\n\n\nThe only protection against making this mistake is when you accidentally do this before other case conditions \u2013 e.g.<\/p>\n\n\n\n
case int:
^
SyntaxError: name capture 'int' makes remaining patterns unreachable<\/code><\/p>\n\n\n\nOtherwise you’re on your own and completely free to make broken code. This will probably be a common error because of our experience with isinstance<\/code> where we supply the type e.g. isinstance(x, int)<\/code>. Which reminds me of a passage in Through the Looking-Glass, and What Alice Found There<\/em> by Lewis Carroll.<\/p>\n\n\n\n‘Crawling at your feet,’ said the Gnat (Alice drew her feet back in some alarm), ‘you may observe a Bread-and-Butterfly. Its wings are thin slices of Bread-and-butter, its body is a crust, and its head is a lump of sugar.’<\/p><\/blockquote>\n\n\n\n
‘And what does it<\/strong> live on?’<\/p>‘Weak tea with cream in it.’<\/p>
A new difficulty came into Alice’s head. ‘Supposing it couldn’t find any?’ she suggested.<\/p>
‘Then it would die, of course.’<\/p>
‘But that must happen very often,’ Alice remarked thoughtfully.<\/p>
‘It always happens,’ said the Gnat. After this, Alice was silent for a minute or two, pondering.<\/p><\/blockquote>\n\n\n\n
Summary<\/h3>\n\n\n\n
There will be lots of mistakes when using the match case even in the most common cases. And more complex usage is not readable without learning a lot more about Pattern Matching. See PEP 622<\/a>.<\/p>\n\n\n\n<\/a>Readable but only if you understand the mini-language<\/figcaption><\/figure>\n\n\n\nBasically it is a yet another mini-language to learn.<\/p>\n\n\n\n
Arguments for Python Pattern Matching<\/h2>\n\n\n\n
Sometimes we need to pattern match and a match \/ case syntax is quite elegant. The way values are unpacked into names is also really nice.<\/p>\n\n\n\n
We will certainly love this feature if we are moving away from duck typing and adopting the programming style of statically-typed languages like Scala. But maybe we shouldn’t encourage this style of programming by making it easier to write in Python.<\/p>\n\n\n\n
Verdict<\/h2>\n\n\n\n
In balance, Python Pattern Matching doesn’t seem to pass the Must-Be-Really-Valuable-To-Justify-the-Increased-Complexity test. And I’m not alone in wondering this (Musings on Python’s Pattern Matching<\/a>). I enjoyed coming to grips with the syntax but I think it is like for else<\/code> and Python Enums – best avoided. But we will see. We can’t always tell what the future of a feature will be – maybe it will turn out to be very useful and one day there will be a third blog post ;-).<\/p>\n","protected":false},"excerpt":{"rendered":"Less is More One of the beautiful things about Python is its simplicity. We don’t want it to end up like those languages which have a designed-by-committee feel where everyone gets to add features and there are many ways of … Continue reading