This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author serhiy.storchaka
Recipients graingert, rhettinger, serhiy.storchaka, tim.peters, ztane
Date 2021-08-01.06:39:17
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1627799957.69.0.626257740311.issue43468@roundup.psfhosted.org>
In-reply-to
Content
I think it was a mistake to use lock in cached_property at first place. In most cases there is nothing wrong in evaluating the cached value more than once. lru_cache() does not use a lock for calling the wrapped function, and it works well. The only lock in the Python implementation is for updating internal structure, it is released when the wrapped function is called. The C implementation uses the GIL for this purpose.

It is hard to get rid of the execution lock once it was introduced, but I think we should do it. Maybe deprecate cached_property and add a new decorator without a lock. Perhaps add separate decorators for automatically locking method execution, different decorators for different type of locking (global, per-method, per-instance, per-instance-and-method).

Java has the synchronized keyword which allows to add implicit lock to a method. As it turned out, it was a bad idea, and it is no longer used in the modern code.
History
Date User Action Args
2021-08-01 06:39:17serhiy.storchakasetrecipients: + serhiy.storchaka, tim.peters, rhettinger, ztane, graingert
2021-08-01 06:39:17serhiy.storchakasetmessageid: <1627799957.69.0.626257740311.issue43468@roundup.psfhosted.org>
2021-08-01 06:39:17serhiy.storchakalinkissue43468 messages
2021-08-01 06:39:17serhiy.storchakacreate