Finding a path forward for `functools.cached_property`

[carljm (Carl Meyer)]

@malemburg

Perhaps a bit sneaky, but since @functools.cached_property() does not advertise being thread-safe in the documentation (unlike for example @functools.cache()), there’s another possible variant of options 2 and 3:

• Add a lock=False kwarg, managing the locking mechanism. Have it default to False, since locking was never advertised.
• Document the existing global locking mechanism and its downsides.
• Work on a locking implementation which uses more fine grained per-instance locking and then advertise using this when done.

I would consider this rather a variant of option 1, since it shares the key feature that functools.cached_property becomes lock-free by default without a deprecation process.

If we want to do option 1, but also keep a locking version available in the stdlib, I think it’s slightly nicer to keep it under a new name (locking_cached_property) rather than using a kwarg.

@malemburg

Finally, use a deprecation phase of two releases to change the lock=False default to lock=True.

Given that evidence suggests most users don’t need locking, and it has overhead, even presuming someone implements per-instance locking I don’t see why we would ever go through the disruption of a deprecation process to change the default to one that is probably less desirable for most users.