2 ms·

I feel it's meant to be a part of the features that try to make Python more viable for functional programming, but when you compare it to the equivalent in Hask

by jolmg 8y ago

I feel it's meant to be a part of the features that try to make Python more viable for functional programming, but when you compare it to the equivalent in Haskell, for example: * You can't nest, like it was mentioned ((x1, y1), (x2, y2)) = makeLine ... * You can't use aliases line@(point1@(x1, y1), point2@(x2, y2)) = makeLine ... * You can't use it on all objects/structures/datatypes Line (Point x1 y1) (Point x2 y2) = makeLine ... * You can't pattern match on it case nextShape of Circle centerPoint radius -> ... Square width height -> ... Triangle point1 point2 point3 -> ... * You can't use it on functions/lambdas \ Line (point1@(Point x1 y1) _) -> ... drawLine (Line (point1@(Point x1 y1) _)) = ... * The syntax in Python 2 doesn't support unpacking the first few elements of a list of variable length. Python 3 added support, though. x1:x2:xs = ...

zephyrfalcon 8y ago
Tuple/list unpacking has been in Python for a long time and likely has nothing to do with catering to the functional crowd, which Guido isn't known for to begin with. Anyway... > * You can't nest, like it was mentioned ((x1, y1), (x2, y2)) = makeLine ... This works fine in Python: ((x1,y1), (x2,y2)) = ((1,2),(3,4)) I don't know what "makeLine ..." returns, but if it doesn't exactly match the tuples on the left hand side, it won't fly in Haskell either. > * You can't use aliases line@(point1@(x1, y1), point2@(x2, y2)) = makeLine ... No, but this works: line = p1, p2 = ((x1,y1), (x2,y2)) = ((1,2), (3,4)) and is more readable IMHO. Point 3, 4 and 5 don't make sense in Python. This is pattern matching, not tuple/list unpacking. (One could argue that tuple unpacking is a form of pattern matching, but that is a different story...)