gh-100288: Specialise LOAD_ATTR_METHOD for managed dictionaries

[Fidget-Spinner]

This specialisation targets the following code:

class A:
 def b(s): ...

a = A()
a.__dict__
def f():
 for _ in range(10):
  a.b() # This LOAD_ATTR_METHOD was previously not specialised.

f()

• Issue: Finish up LOAD_ATTR specialisation #100288

[netlify]

✅ Deploy Preview for python-cpython-preview ready!

Name	Link
🔨 Latest commit	fe02743
🔍 Latest deploy log	https://app.netlify.com/sites/python-cpython-preview/deploys/639c4ad496e5300008bf5de4
😎 Deploy Preview	https://deploy-preview-100289--python-cpython-preview.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[Fidget-Spinner]

Interesting, I can create a reproducer:

import dis
import configparser as c

p = c.ConfigParser()
def f():
 for _ in range(10):
  print(p.optionxform("Test"))

f()
p.optionxform = lambda a:a
f() # supposed to be "Test" but prints "test"

[markshannon]

Is this case common enough to justify the extra instruction?

(Thinking aloud here)
And is this best approach? Can we modify the layout of objects so that it doesn't matter if the __dict__ has been materialized, provided the keys haven't changed?

[Fidget-Spinner]

Is this case common enough to justify the extra instruction?

It's the highest specialisation failure for LOAD_ATTR we currently have (35.5% of 16.2% specialisation failures).

[markshannon]

It's the highest specialisation failure for LOAD_ATTR we currently have (35.5% of 16.2% specialisation failures).

Can't argue with the data 🙂

OK, let's go with this approach. We can always looks for ways to improve the object layout later.

[Fidget-Spinner]

@markshannon is it alright if I merge this?

[markshannon]

@markshannon is it alright if I merge this?

Yes, but I'm not pressing any merge buttons just before Christmas 🙂

[Fidget-Spinner]

Yes, but I'm not pressing any merge buttons just before Christmas 🙂

HAHA right. I'll press it and if anything goes wrong it's 100% on me to fix it :).

[Fidget-Spinner]

Well looks like I'm reverting PRs for Christmas... this PR introduced a race condition in test___xxxsubinterpreters on Windows. I had to run this with -F and it only crashed after 10 runs.

Thread 0x00000430 (most recent call first):
  File "D:\a\1\s\Lib\test\test__xxsubinterpreters.py", line 812 in test_create_thread
  File "D:\a\1\s\Lib\unittest\case.py", line 579 in _callTestMethod
  File "D:\a\1\s\Lib\unittest\case.py", line 623 in run
  File "D:\a\1\s\Lib\unittest\case.py", line 678 in __call__
  File "D:\a\1\s\Lib\unittest\suite.py", line 122 in run
  File "D:\a\1\s\Lib\unittest\suite.py", line 84 in __call__
  File "D:\a\1\s\Lib\unittest\suite.py", line 122 in run
  File "D:\a\1\s\Lib\unittest\suite.py", line 84 in __call__
  File "D:\a\1\s\Lib\unittest\suite.py", line 122 in run
  File "D:\a\1\s\Lib\unittest\suite.py", line 84 in __call__
  File "D:\a\1\s\Lib\unittest\runner.py", line 208 in run
  File "D:\a\1\s\Lib\test\support\__init__.py", line 1100 in _run_suite
  File "D:\a\1\s\Lib\test\support\__init__.py", line 1226 in run_unittest
  File "D:\a\1\s\Lib\test\libregrtest\runtest.py", line 281 in _test_module
  File "D:\a\1\s\Lib\test\libregrtest\runtest.py", line 317 in _runtest_inner2
  File "D:\a\1\s\Lib\test\libregrtest\runtest.py", line 360 in _runtest_inner
  File "D:\a\1\s\Lib\test\libregrtest\runtest.py", line 235 in _runtest
  File "D:\a\1\s\Lib\test\libregrtest\runtest.py", line 265 in runtest
  File "D:\a\1\s\Lib\test\libregrtest\main.py", line 353 in rerun_failed_tests
  File "D:\a\1\s\Lib\test\libregrtest\main.py", line 756 in _main
  File "D:\a\1\s\Lib\test\libregrtest\main.py", line 711 in main
  File "D:\a\1\s\Lib\test\libregrtest\main.py", line 775 in main
  File "D:\a\1\s\Lib\test\__main__.py", line 2 in <module>
  File "<frozen runpy>", line 88 in _run_code
  File "<frozen runpy>", line 198 in _run_module_as_main
##[error]Cmd.exe exited with code '-1073741819'.