Behaviour of pattern matching and class private names is currently ambiguous

[da-woods]

Feature or enhancement

class C:
  def f(self, x):
    match x:
      case D(__something=y):
        return y

Currently (Python 3.10, 3.11) this matches x.__something. Under most other circumstances it'd look up x._C__something. This seems reasonable to me, but doesn't seem to be tested for (so it isn't clear that it's been "decided")

I propose to keep the current behaviour, but add a test so that it's at least "fixed"

Previous discussion

I asked on Python-dev list https://mail.python.org/archives/list/[email protected]/thread/LILLO3MBTVY6ZQT3VNUVXATEPS3ASGQF/ - the one reply suggested the current behaviour was OK

[da-woods]

I'm not sure "type-feature" is quite right, but it's not a bug either...

[JelleZijlstra]

Logically I think we should mangle the name here, because the corresponding non-pattern-matching code performs name mangling:

In [114]: class C:
     ...:     def f(self):
     ...:         if D.__something == 4:
     ...:             pass
     ...: 

In [115]: dis.dis(C.f)
  3           0 LOAD_GLOBAL              0 (D)
              2 LOAD_ATTR                1 (_C__something)
              4 LOAD_CONST               1 (4)
              6 COMPARE_OP               2 (==)
              8 POP_JUMP_IF_FALSE       10

  4     >>   10 LOAD_CONST               0 (None)
             12 RETURN_VALUE

But changing it now would be a compatibility break, and I'm not sure that's worth it. We'd probably have to warn for a few releases if you use an underscored name in a class pattern.

[da-woods]

because the corresponding non-pattern-matching code performs name mangling:

yes - that's why I originally asked about it. I can honestly see both ways being justifiable.

One downside of doing the mangling is that it'd probably leave __match_args__ and keyword names slightly inconsistent since the mangling likely wouldn't be applied to __match_args__. I don't think that's a huge downside though

[gvanrossum]

Closed by adding a test that locks in this behavior. We decided it's not worth updating the PEP (one could argue that it already specifies the current behavior).