Replace cached_property on slotted classes with a new descriptor instead of writing __getattr__

[DavidCEllis]

Summary

This PR reimplements cached_property in slotted classes as a slot wrapping descriptor replacing the current generated __getattr__ implementation.

Accessing the attributes will probably be slightly slower due to going through this descriptor but if the performance is reasonable this will close #1288 #1325 and #1333.

This idea came up again as part of discussion on https://discuss.python.org/t/extensible-cached-property/105188/25. I hadn't realised it would work, but it looks like there was a partial attempt to implement it for attrs before in #1357

I've implemented it for my own attrs/dataclasses-like here (the _SlottedCachedProperty code is mostly identical).

As I saw there were outstanding issues for it and the code is fairly similar I thought you might also find it useful. (Passing all of your existing tests also gave me some confidence that it does work correctly).

---

Changes:

• Adds a _SlottedCachedProperty descriptor class that replaces the slot descriptors after attrs has rebuilt the class.
  • This is very similar to cached_property itself, other than reading/writing/deleting a wrapped slot rather than dict entry.
• Removes the customised __getattr__ function you were making previously.
  • There are probably some redundant tests that were checking the __getattr__ behaviour that are now just checking __getattr__ works in Python.

---

Outstanding issues:

This was already the case for the __getattr__ implementation but I'm now aware of one difference in behaviour this hasn't yet resolved as it would require changing the logic of when you create a new cached property. There's currently a test marked as xfail for this.

import attrs
import functools

for slotted in [False, True]:
  @attrs.define(slots=slotted)
  class Parent:
      name: str = "Alice"
  
  @attrs.define(slots=slotted)
  class Child(Parent):
      @functools.cached_property
      def name(self):
          return "Bob"
  
  # This isn't to imply that this is good
  # just that it's consistent
  p = Parent()
  c = Child()
  
  assert p.name == "Alice"
  assert c.name == "Alice"
  del c.name
  assert c.name == "Bob"  # True without slots, errors under slots.

This is because the cached_property replacement check attrs does skips field names that already exist, so name is skipped in the check and doesn't get replaced. The descriptor would behave like this, but it's never placed.

Pull Request Check List

• Do not open pull requests from your main branch – use a separate branch!
  • There's a ton of footguns waiting if you don't heed this warning. You can still go back to your project, create a branch from your main branch, push it, and open the pull request from the new branch.
  • This is not a pre-requisite for your pull request to be accepted, but you have been warned.
• Added tests for changed code.
  Our CI fails if coverage is not 100%.
• Changes or additions to public APIs are reflected in our type stubs (files ending in .pyi).
  • ...and used in the stub test file typing-examples/baseline.py or, if necessary, typing-examples/mypy.py.
  • If they've been added to attr/__init__.pyi, they've also been re-imported in attrs/__init__.pyi.
• Updated documentation for changed code.
  • New functions/classes have to be added to docs/api.rst by hand.
  • Changes to the signatures of @attr.s() and @attrs.define() have to be added by hand too.
  • Changed/added classes/methods/functions have appropriate versionadded, versionchanged, or deprecated directives.
    The next version is the second number in the current release + 1.
    The first number represents the current year.
    So if the current version on PyPI is 22.2.0, the next version is gonna be 22.3.0.
    If the next version is the first in the new year, it'll be 23.1.0.
    • If something changed that affects both attrs.define() and attr.s(), you have to add version directives to both.
• Documentation in .rst and .md files is written using semantic newlines.
• Changes (and possible deprecations) have news fragments in changelog.d.
• Consider granting push permissions to the PR branch, so maintainers can fix minor issues themselves without pestering you.

[codspeed-hq]

CodSpeed Performance Report

Merging #1488 will degrade performances by 71.98%

_{Comparing DavidCEllis:descriptor-cached-property (5e19f82) with main (850084d)}

Summary

❌ 1 regression
✅ 13 untouched
🆕 1 new

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Benchmarks breakdown

	Benchmark	BASE	HEAD	Change
🆕	test_create_cached_property_class	N/A	1.1 s	N/A
❌	test_repeated_access	255 µs	910.2 µs	-71.98%

[DavidCEllis]

Oof, that's worse than I thought. I have one idea that should make it slightly better, but probably still significantly worse than the direct access it has on main.

[DavidCEllis]

Ah, it would have needed to be on main to see the difference. I haven't used codspeed before, sorry for the noise there. Locally it seemed to be significantly faster to construct classes at least. Probably less important than attribute access, but worth noting it's not uniformly worse performance-wise.