Please no smuggery.
Here's a bit more context on why it's less attractive to have
match in Python.
match statement maybe isn't a good fit for Python, at least not as much as
match in Racket.
Racket and other FP languages usually have
match expressions, whereas Python has a
match statement (which is understandable since Python is primarily an imperative language). Also, different from Racket, Python in general uses a single scope for everything defined in a function or method. Therefore, a
match statement in Python isn't a good fit for the language, different from the
match expression in Racket.
Here's how it plays out. First, let's see a Racket example. (I'm not going into details, I only want to show how Python differs.)
(define a 1)
(define b '(2 3))
[(list a b)
(printf "a = ~a~n" a)
; '(2 3)
(printf "b = ~a~n" b))
match expression (used here like a statement) defines it's own scope. The values
b in the
match expression don't affect anything outside the
On the other hand, this is how it looks in Python:
a = 1
b = (2, 3)
case (a, b):
# 2 (was 1)
print("a =", a)
# 3 (was (2, 3))
print("b =", b)
case assigns new values (2 and 3, respectively) to the variables
b - and this change is visible outside the
Python has become a complex language, and not everyone wants it to become even more complex.
Despite the superficial appearance, Python has become rather complex over the years. For example, look at the currently supported special method names. I'm not going into details, but many people (me included) think that Python has accumulated already too much complexity, so it wouldn't be advisable to add even more, for example in form of the
match statement with its own "sub-language" rules. Larry Hastings explains it well. Here's some more discussion along these lines.
Note that this is a different line of thought from whether someone personally likes the
match concept. For example, I do like
match in Racket and Rust, but I'm still skeptical whether it should have been added to Python.