> `np` analogue is quite a stretch and far-fetched, really. I don't disagree. But `_` is a valid identifier so it shouldn't be special. The solution is incredibly simple: allow repeated identifiers just like in assignment so there is no need for a special wildcard symbol.
> ...<INTUITION ARGUMENT>... I disagree but this is philosophical discussion which I would rather not go down. > ...<POINT ABOUT FUNCTION PARAMETERS>... That's reasonable, although I would argue that a match is more like a for loop (which allows arbitrary assignment) than a function definition. I do understand your point though. However, I still think the inability to match against a constant not in a namespace is very annoying and could be overcome with some explicit syntax. It's reasonable for this syntax to only allow NAME to be bound (many places in the grammar do this, def, class, as, ...) but I haven't seen a satisfactory reason why there *shouldn't* be support for NAME constants; just reasons for why it's tricky. You (or one of the authors) argue against `.constant` as a matching syntax by saying: "..., it introduces strange-looking new syntax without making the pattern syntax any more expressive." but this is obviously false. It clearly does make the syntax more expressive, it allows one to express something naturally without needing to create an auxiliary structure (or the match syntax doesn't make the language more expressive either). Yes namespaces are a great idea but as a consenting adult I should be free to have constants that are not in a namespace. My constant may come in any number of forms that are not conducive to simply "wrapping it in a namespace", for example it may be used in other modules (so wrapping it would require external changes) or it might be a closure variable and so would require some explicit wrapping step. Further, you argue elsewhere that the we shouldn't worry about a syntax being strange because it's new so of course it's going to be different. Yet for invoke this reasoning as a way to reject solutions to the NAME constant issue. Pick one. (preferably the version that includes match syntax and some strange new syntax for explicit constants because I super want the match syntax). Caleb Donovick On Fri, Jul 31, 2020 at 12:40 AM Tobias Kohn <ko...@tobiaskohn.ch> wrote: > Hi Caleb, > > I will only answer to the second part, as the wildcard issue has > been brought up and discussed time and again, and the `np` > analogue is quite a stretch and far-fetched, really. > > One thing that stood out a bit to me as I feel to have seen it a > couple of times is the question of intuition, so I will add a few > more general thoughts to that... > > > [...] but it seems quite unintuitive to me [...] > > > [...] don't necessarily make it intuitively clear [...] > > > > Intuition (or lack thereof) has already been brought forward > as an argument a couple of times. I would just like to briefly > point out that there is no such thing as universal intuition in > the field of programming. We all have different training, > skills, preferences and experiences, which make up what > we call 'intuition'. But what is intuitive is usually something > completely different to C-programmer than to a Haskell- or > Lisp-Programmer, say. And since pattern matching is really > a new feature to be introduced to Python, a feature that can > be seen in different lights, there is no 'Python-Programmer > intuition' that would apply in this case. > > As for beginners, virtually every part of programming is > unintuitive at first. Even something innocuous-looking like > assignment is often reason for confusion because `3 + 4 = x` > would probably be more 'intuitive'. But there is good reason > with regards to the bigger picture to stick to `x = 3 + 4`. > > A Python-programmer (at any level) not familiar with pattern > matching will most likely not understand all subtlety of the > syntax---but this is alos true of features like `async` or the > `/` in parameters, say. I would argue, though, that the clear > choice of keywords allow anyone to quickly look pattern > matching up and get informed on what it does. So, we do > not need to come with something that is entirely 'intuitive' > and 'self-evident'. But by sticking to common convention > like `_` as wildcard, we can help quickly build the correct > intuition. > > > In your examples, for instance, it is perfectly obvious to me > that you cannot directly assign to attributes and it would in > fact look very weird to my eyes if you could. Your use case > is quite similar to initialisers and you are arguing that you > would like being able to write: > ``` > *class* Point: > *def* __init__(self, self.x, self.y): > *pass* > ``` > rather than the more verbose: > ``` > *class* Point: > *def* __init__(self, x, y): > self.x, self.y = x, y > ``` > I do not think that this would be a good idea for either > parameters or patterns. After all, pattern matching is > **not** assignment, even though it is related to it, of > course. > > Kind regards, > Tobias > > > > Quoting Caleb Donovick <donov...@cs.stanford.edu>: > > Adding this feature would be a giant quality of life improvement for me > and I really hope it succeeds. So I have been trying to keep up on the > debate in this and related thread. > > While I do want this feature, I agree with a lot of the issues people are > raising. > > First I agree that _ should not be the wildcard symbol. Or rather the > hobgoblins in my mind think that if _ is to be the wildcard symbol it would > be more consistent with assignment if it was bound to the last value it was > matched with (as should other repeated identifiers) e.g., > > match pt: > case (x, _, _): > assert _ == pt[2] > > > I understand the authors rationalize the decision based on conventions > with the gettext module. I find these arguments very unconvincing. It's > like saying the identifier np should be forbidden from appearing in cases > because it's frequently used as the name of numpy. If there is to be a > wildcard symbol (that does not bind and is repeatable) it should not be a > valid identifier. > > Second, the distinction between a capture and constant value pattern > should be more explicit. I don't have any great insight into the color of > the shed beyond the numerous suggestions already made (name=, ?name, > etc...), but it seems quite unintuitive to me that I can't capture into a > namespace nor match a constant without a namespace. It is also unclear to > me why it would be so terrible to add a new token or abuse an existing one. > > > Honestly, it doesn't help the case for `?` that it's been proposed as a > mark for both capture patterns and value patterns (by different people, > obviously :-). > > I agree that most of the proposed sheds don't necessarily make it > intuitively clear what is a capture variable vs what is a constant. > However they do give the programmer the ability to choose. > > For example if I want to modify the motivating example from the PEP > slightly to copy attributes from one point to another I can't express it > concisely: > > def update_point_3d(p: Point3d, pt): > match pt: > case (x, y): > p.x, p.y = x, y > case Point2d(x, y): > p.x, p.y = x, y > ... > > > > (Okay I could have just called the original make_point_3d and unpacked the > results but it would require the creation of an unnecessary temporary.) > > However if the capture was explicit and any valid target could be used as > a capture variable then I could express this cleanly: > > def update_point_3d(p: Point3d, pt): > match pt: > case (p.x=, p.y=): > pass > case Point2d(p.x=, p.y=): > pass > ... > > > > - Caleb Donovick > > > > > > _______________________________________________ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/YEHZ4W6CLHMHZJHVO6MZYF7VSL3ZNYFU/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/RQDWPDYU4ZFXHI6RJ3AGDJUHI5LGLHSV/ Code of Conduct: http://python.org/psf/codeofconduct/
