Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

    case Point(x, y) if x == something

Where's the problem?


Syntax cleanliness is ultimately subjective, so if you don't see a problem with that then I don't think I can persuade you. To me, it just seems obvious that it's more painful than what I wrote. But I'll mention a couple of specific reasons anyway:

* The most concerning thing is knowing to write that in the first place. I think that if the ? syntax were the real one then you'd soon get used to writing a snippet like in my comment, but with the current syntax it's always going to take a bit of mental mind bending to come up with what you've written.

* Even if you get it right when writing it, what you've written is vastly more verbose, and adding that redundant variable name (twice!) is just going to be distracting when reading it back.

By the way, what you wrote is not equivalent to what I wrote (I wonder if that means your snippet is not as obvious as you're suggesting): you've matched against "something" rather than "x". Instead you'd need to do:

    case Point(also_x, y) if also_x == x:


> The most concerning thing is knowing to write that in the first place

This is something you learn from reading the docs / book on the feature. This applies to all language features.

> Even if you get it right when writing it, what you've written is vastly more verbose

Slightly more verbose, but also more consistent with the rest of Python syntax. Python syntax already has `if` clause that's well understood, while you're proposing a special-case syntax. I believe language consistency beats brevity, and explicit is better than implicit.

BTW the ? syntax looks to me very similar to optional / null-aware / error-aware dereferencing operator used in some other languages (Kotlin, Groovy, Rust).


> This is something you learn from reading the docs / book on the feature. This applies to all language features.

Surely you agree that, even having read and understood documentation for a language feature, there are differing levels of difficulty in using it? That depends on intrinsic complexity of the feature and also the incidental complexity from the design of the language feature. Your comment seems to imply that it doesn't matter what syntax the language feature uses because you'll have to learn about it in any case. I'm sure you don't really mean that!

> I believe language consistency beats brevity, and explicit is better than implicit.

I agree with both parts of this statement, I just disagree that the syntax they chose satisfies it.

The syntax is not consistent with anything else, because nowhere else can you have (0, x, foo.y) mean "assign to x (but don't assign to 0 or foo.y)". That includes if statements, with statements, and left hand side of assignment statements. Choosing a new syntax for something that has different behaviour from existing syntax actually is being consistent.

Similarly, using a character like ? (or some other distinctive syntax) to demark which parts are being used for pattern matching is being explicit. In Point(x, foo.y, 0), saying that only x is assigned to because it's not a literal or dotted seems like a great example of implicit behaviour to me.

Again, like I said at the start, this is all subjective so I think we'll have to agree to disagree. I just wanted to object to those quoted sentences because it looked like you were saying that it is objectively true that ? syntax is implicit and inconsistent while the syntax they chose is explicit and consistent - and that isn't objectively true.


Ah, I completely agree with what you have written here. My earlier post applied to using the if clause for matching to the variable value instead of capturing the value from the object.

I view pattern matching from a bit different angle - instead of viewing the case expression as answering "does the object match the pattern", I view it instead "can the object be deconstructed to a thing looking like the pattern". That is, if you write the exactly same expression after matching on the right side, it should evaluate to the original object being matched. And I believe this holds in Python just as in other languages with pattern matching.

However, Python way of making it work is indeed a bit strange - because pattern matching is allowed to mutate variables from the outer scopes, while in some other languages I'm used to, capturing symbols just shadow the symbols in the outer scope, without changing them. This is a bit scary part of Python implementation.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: