Assignment is not generally a side effect, and even if it were, matched branches in a switch statement potentially having side effects or externally visible variable (re)assignments is normal in languages with switch. (Ironically, match-based assignments visible outside the pattern match expression aren’t typical in languages with pattern matching, so actually the behavior you describe is more typical of switch statements than pattern matching, which is typically a block-scoped expression with local bindings.)
However, there are some special cases where variable scope is smaller than a whole function, e.g. within list comprehensions.
Or we can think of a list comprehension as a function doing a loop/collect under the scenes.
I don't really understand the logic behind this comment. You're pointing this out like it's some contradiction in people's opinion.
But it's not like "block scope" is the one and only determinant of whether a language is good or bad, so lack of that alone would negate the above statement.
js could be bad and python good, regardless of whether Python lacks block scope. Doubly so since js also lacks it by default, and has only sort of tacked-it on with let/const.
But the even better answer is that both are languages with different strenghts and tradeoffs, that JS did have several bad design decisions early on, that both have evolved, and x=bad, y=good is a fanboi reaction, not a developer reaction.
Since JavaScript tends to have many more unnamed functions defined in the middle of long functions, compared to Python (which tends towards named functions, classes, or comprehensions), block scoped variables (or more precisely simple and rigorous rules about scoping) are much more useful and important in JavaScript than they would be in Python, since if there is a part of a Python function where some variable shouldn't be visible it's probably a long and complex function which can and should have its variable scopes refactored apart.
And this is supposed to be bad because?
They had a problem, used a language to solve it, they've solved it, end of story.
If they're satisfied with their solution, and it works for their purpose (and for their companies/organizations purposes), who is to day it's not OK?
Perhaps they are professionals doing a job, not dilettante nerds trying different languages and idioms for fun...
Programming is a tool, with the goal being building things that help the user.
1) it's "opt in" (you need to explicit implement the dunder method) and
2) it's only for specific classes, you cannot change the behavior of 1 == "one"
More clearly because builtins are protected from monkey-patching, you can’t change the behavior of == where both operands are builtins. “Only for specific classes” implies the scope of applicability is much narrower than it is.
Well, yes, but actually, no.
A switch operator, at least in most other languages, uses comparison to select a branch. Only comparisons are performed (either with each branch or optimized for direct access) but no other side effect. Pattern matching, as with other languages too, tries to 'match' the variable to the pattern. If it succeeds, then the branch is taken and the variables (if any) are assigned, which in python means that they are assigned to the whole current function. This is a big side effect.
And that's the main problem, the variable constants. Once you understand the issue it is relatively easy to fix, but for a newcomer this will probably be a few minutes of searching and debugging.
Python don't have a switch statement, at least not yet, pattern matching is just another similar feature that can be adapted to work similarly, like the chain of elifs and the lambdas dictionary. However if you want to say otherwise...at least give the warning of the constants at the beginning, not at the end.