![]() 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.Python Dictionaries Access Items Change Items Add Items Remove Items Loop Dictionaries Copy Dictionaries Nested Dictionaries Dictionary Methods Dictionary Exercise Python If.Else Python While Loops Python For Loops Python Functions Python Lambda Python Arrays Python Classes/Objects Python Inheritance Python Iterators Python Scope Python Modules Python Dates Python Math Python JSON Python RegEx Python PIP Python Try. 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. Packing: You might have seen args and kwargs in a python function definition. is used for unpacking positional arguments. Unpacking: During function call, we can unpack python list/tuple/range/dict and pass it as separate arguments. But there would be no conversion involved, and IMO there shouldn’t be. In python functions, we can pack or unpack function arguments. 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 |