This is trying to achieve a poor-human's multiple-dispatch with match-case syntax
PEP 622 – Structural Pattern Matching
91–100 of 131 posts
Re: PEP 622 – Structural Pattern Matching
#92Earlier quoted context omitted.
At the current rates, it seems like it's only going to be another 5 years or so before Python is straight-up a more complicated language than Perl 5. What it lacks in frankly bizarre corner cases it's going to make up for in subtly bizarre corner cases. I used to feel like I could define __getattr__ or __setattr__ and understand the implications, but that's getting increasingly terrifying.
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.
Re: PEP 622 – Structural Pattern Matching
#93This PEP is burying the lede -- it introduces a `@sealed` decorator, which gives python ADTs: https://www.python.org/dev/peps/pep-0622/#sealed-classes-as-...
Re: PEP 622 – Structural Pattern Matching
#94Earlier quoted context omitted.
btw, my favorite FP-hack: let-in expressions with lambdas OR list comprehensions: let x = foo in expr can be [expr for x in (foo,)][0] (kinda reads like a Haskell `where` clause!) or: (lambda x = foo: expr)() useful in a pre-walrus-operator REPL :)
If you want to program in Haskell, why don’t you get a job programming in Haskell rather than inventing something so ugly? You would not get through code review with that in any shop that has discipline.
> You would not get through code review with that in any shop that has discipline.
... and i'd never think to try! that's why i mentioned using it in a REPL and called it a hack :) it's just fun. i played around with bytecode-rewriting too, doesn't mean i'd use it in production.
PS. for a less extreme version, the 1-elem-tuple trick is useful if you need an intermediate variable in a listcomp:
[
y+y
for x in my_list
for y in (foo(x),)
]
Re: PEP 622 – Structural Pattern Matching
#95Re: PEP 622 – Structural Pattern Matching
#96If you like pattern matching and Python, I recommend you check out http://coconut-lang.org/ which compiles to Python.
This basically is used by someone who forced to use python's libraries.
Re: PEP 622 – Structural Pattern Matching
#97This PEP is burying the lede -- it introduces a `@sealed` decorator, which gives python ADTs: https://www.python.org/dev/peps/pep-0622/#sealed-classes-as-...
I guess then python can have either and maybe? That would be real nice. working with exceptions sucks...
Re: PEP 622 – Structural Pattern Matching
#98This is the first PEP I’m really excited about. I hope the design is given more careful consideration, though, because destructuring in this manner more broadly across the language would also be killer.
My biggest concern is the class matching syntax. I feel like that would be much better deferred to a lambda style function or similar. The syntax matches instantiating a new class instance exactly, which seems like it could cause a lot of problems for tools that read and manipulate syntax.
Re: PEP 622 – Structural Pattern Matching
#99Interesting proposal, but I'm cringing at yet another overload for the * symbol. a * b == "a times b" a * * b == "a to the power of b" f(* a) == "call f by flattening the sequence a into args of f" f(* * a) == "call f by flattening the map a into key value args for f" [* a] == "match a sequence with 0 or more elements, call them a" Am I missing something? I know these all occur in different contexts, still the genera…
Yes, that it is pretty much already part of the language like this. This works: a, *b = (1, 2, 3, 4) b will be [2, 3, 4]
Not only that, but this also works!
a, *b, c = (1, 2, 3, 4)
a == 1, b == [2, 3], c == 4Re: PEP 622 – Structural Pattern Matching
#100So it’s actually a smart switch statement. Seems like it doesn’t create instances when you’re doing Node(children=[Leaf(value="("), Node(), Leaf(value=")")]) instead: 1. Node means "is instance of Node". 2. Everything in between () is "has an attribute with value". 3. List means "the attribute should be treated as a tuple of".. etc.. Very confusing, this definitely needs another syntax, because both newcomers and exp…
I would prefer something like:
match node:
on (time _ 1 @ 0, foo _ 2, bar _ 3, baz _ any, status _ 1 @ -1):
do_something()
rematch do_something_2(foo)