gh-94499 Add test for private name mangling in class pattern matching #94500
Conversation
There was a problem hiding this comment.
Thanks for the test. I think the readability could be a bit improved a bit (it took me a second to figure out what this test was doing)... what do you think of this version?
If you don't like it, at the very least we should change all of the setattrs to normal attribute assignments.
|
Ah, I forgot that this entire test is inside of another class, which mangles the |
There was a problem hiding this comment.
LG with one suggestion. I approve of locking in this behavior. @brandtbucher Do you think we should add a clarification to PEP 634?
I think the current wording ("The keyword is looked up as an attribute on the subject.") is fine as-is, but I wouldn't reject a PR proposing to modify it. Nobody really reads PEP 634, though. 🙃 |
The current status quo is that private attribute names are not mangled when a class is matched. I've added a test to document/legimize this behaviour.
Co-authored-by: Brandt Bucher <[email protected]>
da-woods
force-pushed
the
pattern-match-mangling
branch
from
530d483 to
97554c9
Compare
|
Rebased to undo a git mishap! Sorry! |
|
Since it's just a test I don't feel that it needs to be backported, though we could probably backport to 3.11 and 3.10. @brandtbucher What do you think? |
|
Nah, I’m not worried about this behavior regressing on older branches. |
The current status quo is that private attribute names are not
mangled when a class is matched. I've added a test to
document/legitimize this behaviour.
I don't think this needs a news entry (but can create one if required).
I asked about this in Python-dev and it wasn't clear if the current behaviour was by design or not. My view is that it seems reasonable so the right thing to do is to "lock it in" by testing for it, but I'm also happy for