feels like languages are converging.
PEP 622 – Structural Pattern Matching
111–120 of 131 posts
Re: PEP 622 – Structural Pattern Matching
#112Earlier quoted context omitted.
Although it won't be as concise, you can use guards to emulate this feature with match data: case [x1, x2] if x1 == x2: ... I agree on this being a fantastic addition to the language. I've sorely missed not having pattern matching in Python after using Rust.
Guards feel superfluous if the x, x pattern can be trivially lowered into a guard.
More vice versa. Guards look more general (being able to express not-equal, and less-than etc), so special semantics for `x,x` only seem warranted if it's very common.
Re: PEP 622 – Structural Pattern Matching
#113Earlier quoted context omitted.
Pattern matching is implemented as syntaxic sugar on top of if/else in the bytecode. Behavior doesn't change at all.
Uhhh... yeah but that's true of almost every language feature, right? I love pattern matching but I think the point is that Python risks turning into a "kitchen sink" language with too many syntactical forms to keep in ones head if this continues.
I'm sure I think of a dozen python syntax trick most python devs do not not exist.
Python is good enough without them that they never had to learn them.
In fact, today I'm teaching "advanced python" to someone that has been coding in python for a year.
This person didn't know about list comprehensions.
I would not worry about that.
Re: PEP 622 – Structural Pattern Matching
#114The implicit isinstance the repurposing of the constructor syntax all seems very un-Pythonic.
Re: PEP 622 – Structural Pattern Matching
#115Can someone explain to me the history behind Python's aversion to switch statements? I get Python is opinionated and I'm not trying to start a language war, it was just never clear to me why the `if ... elif` pattern was the preferred idiom.
It's a remnant from the time when Python strived for simplicity and resisted adding syntax. Just like the decision against adding a ternary operator, etc. The alternative ways (dict of functions or if chain) were considered good enough weighed against the sin of adding relatively rarely used syntax.
Re: PEP 622 – Structural Pattern Matching
#116>Note that because equality (__eq__) is used, and the equivalency between Booleans and the integers 0 and 1, there is no practical difference between the following two:
>case True: ... case 1: ...
From practical perspective this is great, but I can imagine many cases where one could want to differentiate between those.
On one hand the number usually can be nested inside a structure and matching on == is more flexible. On the other hand matching on 'is' is still letting users relax this behaviour and allows matching on type of primitives as well.
Re: PEP 622 – Structural Pattern Matching
#117Very interesting. This PEP is still in draft state, but I am interested to see how the community will react. For me, I have a few thoughts: 1) This is really close to Erlang/Elixir pattern matching and will make fail-early code much easier to write and easier to reason about. 2) match/case means double indentation, which I see they reasoned about later in the "Rejected ideas". Might have a negative impact on readabil…
I have a visceral dislike of pattern matching. Lisp shows just how much people will abuse it in real-world production codebases. It becomes impossible to understand even simple logic without comments. I’d link to some examples, but I’m on mobile; suffice to say, pull up the emacs codebase and read through some of the more advanced modules like edebug.el. I’m not certain that one uses pattern matching, but it’s a perf…
People use pattern matching all the time in ML or rust or haskell or Scala or Elm. It's totally uncontroversial there, and it's helpful to readability, not harmful. Erlang and Elixir also show it works in untyped languages pretty well.
Re: PEP 622 – Structural Pattern Matching
#118Can someone explain to me the history behind Python's aversion to switch statements? I get Python is opinionated and I'm not trying to start a language war, it was just never clear to me why the `if ... elif` pattern was the preferred idiom.
I came to Python after ~5 years of programming in C-style languages (about 15 years ago) and the lack of a switch statement may be the one thing about Python that demonstrably made me a better coder. When I discovered there wasn't one, I was really annoyed and went digging for an explanation. The one I found was a suggestion if you are reaching for a switch statement, you're (probably) doing something wrong. This is…
Can you give an example? I've never heard of this recommendation and I have a bit of trouble imagining it in a way that is simpler than a bunch of if-else
I came up with the following, and that definitely doesn't convince me.
def call_a():
pass
def call_b():
pass
def default_func():
pass
myswitch = {
"a": call_a
"b": call_b
}
myfunc = myswitch.get(x, default_func)
myfunc()
if x == "a":
pass
elif x == "b":
pass
else:
passRe: PEP 622 – Structural Pattern Matching
#119Earlier quoted context omitted.
Yeah, came here to say the same thing. Disappointing to have to write this: match shape: case Square(l): area = l * l case Rectangle(l, w): area = l * w case Circle(r): area = (PI * r) ** 2 when I want to just write this: area = match shape: case Square(l): l * l case Rectangle(l, w): l * w case Circle(r): (PI * r) ** 2 I'm almost guaranteed to forget (or mistype) the `area = ` at least once in any match clause of le…
That works almost exactly in Ruby. I really wish Python and Ruby would have a child.
Funny. Having worked extensively with Ruby and less so with Python, I think what I really want is expression-oriented Python.
Ideally as a next version of Python. But I think Julia and Nim come to mind as related to these concepts.
Re: PEP 622 – Structural Pattern Matching
#120Earlier quoted context omitted.
Uhhh... yeah but that's true of almost every language feature, right? I love pattern matching but I think the point is that Python risks turning into a "kitchen sink" language with too many syntactical forms to keep in ones head if this continues.
I'm sure I think of a dozen python syntax trick most python devs do not not exist. Python is good enough without them that they never had to learn them. In fact, today I'm teaching "advanced python" to someone that has been coding in python for a year. This person didn't know about list comprehensions. I would not worry about that.
Sorry, are you trying to argue for or against the proposition that Python is on track to be straight-up more complicated than Perl 5 at this rate? Your tone suggests you think you're arguing against it, but all the evidence you're bringing is for the proposition.