Empresas
Empleos
  • Sobre nosotros
  • Soluciones
    • Publicación de vacantes
      Publica tu vacante y recibe candidatos calificados en 48h.
    • Evaluación de candidatos
      500+ pruebas técnicas y psicológicas, más anti-fraude.
    • Headhunting
      Búsqueda ejecutiva a la medida de principio a fin.
    • Nómina + EOR
      Dispersión de nómina y EOR en más de 15 países de LATAM.
  • Precios
  • Empleos

0

260
Vistas
Python LRU cache's global and per instance behavioral differences

I'm going through the implementation details of Python's LRU cache decorator. To understand the behavior of the lru_cache decorator in different scenarios properly, I've also gone through the following SO answers:

  • Python LRU Cache Decorator Per Instance
  • Python: building an LRU cache
  • Python LRU cache in a class disregards maxsize limit when decorated with a staticmethod or classmethod decorator

So far, I can tell that the caching behaviors are different in these 3 scenarios:

  1. Decorating a function in the global namespace.
  2. Decorating an instance method in a class.
  3. Decorating a method in a class that is later on decorated with a staticmethod or classmethod decorator.

The first case is the happy path where each function decorated with the lru_cache decorator has its own cache. This is already well documented. In the second case, the cache is shared among multiple instances of the class where each instance will have different keys for the same argument of the instance method. This is explained quite well in the last question that I've listed. In the third case, the cache is also shared among multiple instances of the encapsulating class. However, since static method or class method don't take self as their first argument, the instances of the class won't create separate cache entries for the same arguments.

My question is—what implementation detail defines this behavior? In the implementation of lru_cache function, I can only see that a local cache dictionary inside the _lru_cache_wrapper function, is saving up the cache entries. Here's the snippet:

def _lru_cache_wrapper(user_function, maxsize, typed, _CacheInfo):
    
    sentinel = object()          
    make_key = _make_key         
    PREV, NEXT, KEY, RESULT = 0, 1, 2, 3   

    cache = {} # This is a local dict, 
               # then how come the instance cache entries are shared?

What I don't understand is how is this local cache dictionary is shared among the instances of a class when the lru_cache decorator is applied to a method that resides in the class? I expected it to act the same as the first case where every entity has its own cache and nothing is shared.

over 4 years ago · Santiago Trujillo
Responde la pregunta
Encuentra empleos remotos

¡Descubre la nueva forma de encontrar empleo!

Top de empleos
Top categorías de empleo
Empresas
Publicar vacante Precios Comercial
Legal
Términos y condiciones Política de privacidad
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomiéndame algunas ofertas
Necesito ayuda