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

On 2/26/22 10:04, Zac Medico wrote:
> On 2/23/22 20:14, Matt Turner wrote:
>> From: "Wolfgang E. Sanyer" <[email protected]>
>>
>> Reviewed-by: Matt Turner <[email protected]>
>> Signed-off-by: Wolfgang E. Sanyer <[email protected]>
>> ---
>>   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