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

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.
-- 
Thanks,
Zac