![]() ![]() It starts with comparing the first element from each of the tuplesĬase1: Comparison starts with a first element of each tuple. If they do not compare to =, then it proceed to the second element and so on. The comparison starts with a first element of each tuple. (company, emp, profile) = x # tuple unpackingĪ comparison operator in Python can work with tuples. I don’t know, I’m slightly warming to the idea, but I don’t know that I’m warm enough to support adding yet more syntax to the language.X = ("Guru99", 20, "Education") # tuple packing Sure it works in match statements, but taken out of the context of multiple cases, its a bit too implicit and not useful enough. That’s just isinstance and raise in disguise. What are we going to do, write something like this: float(x) = y One problem I see is that iterable unpacking has many obvious applications for builtin types, but its harder to see useful applications for this when it comes to builtins. (This can be re-written as a match with two cases, but not one case.) We’re modelling it as: if isinstance(p, Point): So rather than modelling Point(x, y) = p as equivalent to match p: This would have to include an implicit type check, not an assertion. I think it also hurts your case to keep mentioning “assertions” since the critical feature of assertions is that they can be turned off. Since this proposal is being explicitly described as pattern matching generalised to assignments, it is relevent that the behaviour is not the same as pattern matching. Sure, but that’s not the behaviour of the match.case statement. Has a very obvious parallel: = a_list # Throws `ValueError` Point(x, y) = some_other_object # Throws `TypeError` And that’s why, in my opinion, it would be better to use the match keyword in the one-line assignment, such as “match = some_seq” - that way, you guarantee that it’s using match/case semantics rather than regular unpacking. This is the sort of subtle difference that means that arbitrarily extending assignment to support types of match/case structures is going to create weird edge cases. So it will never match something that is iterable but isn’t a sequence. If it does, it THEN unpacks the sequence and assigns it. ![]() It first queries the sequence to see if it has length 2. It will succeed or fail based on the actual results of iteration.īut “case :” in a match statement is specifically a sequence unpack. When you do “ = thing”, Python does a two-element unpack of thing (which iterates over it three steps, and will fail if either it stops short of two or if it yields a third item), then assigns them. > a_thing = iter() # reinitialize since it was consumed It’s true that they behave identically in the example you gave, but consider this: > a_thing = iter() Yes, but they’re still going to be confusingly similar, since the syntax in a match statement is NOT the same as the almost identical syntax in unpacking assignment. Please correct me if I misunderstood your point. The argument that we would be “inventing a confusingly almost-the-same-but-different behaviour” may be valid but it is also already the case for iterables. In both cases, an “assertion” is (would be) performed on assignment, whereas a match case would fall through. = a_list # Throws `ValueError` `a_list` is a one-item list Point(x, y) = some_other_object # Throws `TypeError` `some_other_object` is not a `Point` What I’m saying is that a hypothetical: Point: (Try this using an iterable of (print("Hello, world") for _ in range(3)) and then vary the length it’ll never match the case statement, but always be attempted for the unpacking.) In that the first one will accept any iterable whatsoever, attempt to retrieve four values from it, and if it gets precisely three, assigns them the second will ONLY match a sequence of length three. There’s also a notable, though perhaps also subtle, distinction between these two constructs: = iterable Otherwise, there’d be this weird disconnect regarding the _ special name (which is just a variable name elsewhere), which is bound to cause very very subtle confusion somewhere, possibly in a project that uses I18n tools. If this sort of syntax were to be added, I would want to see the match keyword used in it somewhere, since the semantics of match/case are not quite identical to sequence unpacking. ![]() But there would be no conversion involved, and IMO there shouldn’t be. ![]() These semantics could be seen as broadly equivalent to the assert-and-assign described. Print(f"Y= and the point is on the y-axis.") With the introduction of PEP-622, we have the elegant and succinct syntax of matching a value by an instance of a class while also assigning attribute values of the instance to variables, e.g.: class Point: ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |