Re: [gentoo-portage-dev] [PATCH 4/4] portage.eapi: use functools @lru_cache decorator instead of custom implementation

[Zac Medico]

On 2/26/22 10:04, Zac Medico wrote:

> On 2/23/22 20:14, Matt Turner wrote:
>> From: "Wolfgang E. Sanyer" <WolfgangESanyer@×××××.com>
>>
>> Reviewed-by: Matt Turner <mattst88@g.o>
>> Signed-off-by: Wolfgang E. Sanyer <WolfgangESanyer@×××××.com>
>> ---
>>   lib/portage/eapi.py | 155 ++++++++++++++++++++------------------------
>>   1 file changed, 72 insertions(+), 83 deletions(-)
>>
>> diff --git a/lib/portage/eapi.py b/lib/portage/eapi.py
>> index 56e64620a..efcc6c2a0 100644
>> --- a/lib/portage/eapi.py
>> +++ b/lib/portage/eapi.py
>> @@ -2,12 +2,10 @@
>>   # Distributed under the terms of the GNU General Public License v2
>>   import collections
>> -import operator
>> -import types
>> -
>> -from portage import eapi_is_supported
>> +from functools import lru_cache
>> +@lru_cache(None)
>>   def eapi_has_iuse_defaults(eapi):
>>       if eapi is None:
>>           return True
>> @@ -15,6 +13,7 @@ def eapi_has_iuse_defaults(eapi):
>>       return eapi != "0"
>
> I think this patch misses the point of the original caching mechanism.
> It doesn't make sense to cache results of the individual eapi_*
> functions if they no longer contribute to the _eapi_attrs cache.


To clarify, the only reason that the eapi_* functions were cached was so 

that they would trigger population of the _eapi_attrs cache. In the 

absence of this_eapi_attrs cache population feature, I doubt that it's 

very useful to put the lru_cache on the indivdual eapi_* functions.

-- 

Thanks,

Zac