Re: Simplified Python caching

[Bruno Haible]

> > Using '@lru_cache(maxsize=None)' would let Python deal with all of
> > this caching for us.
> 
> It's better to not do it, and keep the code as-is.

I gave
> Two reasons:
> 
>   * As I already mentioned, it's good to keep the code understandable,
>     without going "all-in" on all possible features that the programming
>     language offers.
> 
>     I'm all for simplifications that keep us at the same level of
>     abstraction (such as using 'open' instead of 'codecs.open'). But here,
>     we would be starting to use the meta-level ("higher-order functions").
>     This can be useful in some cases, e.g. Java JUnit makes good use of it
>     in order to avoid repetitive code. But it's an extra steep piece of
>     learning curve. For saving 9x 3 lines of code? Not worth it.
> 
>   * It would introduce hidden global state, that is a constraint for
>     future developments. Namely, if in the future we would need a GLModule
>     to become mutable (not sure this would be a good decision, but anyway),
>     then these caches behind the scenes would become a big surprise. It's
>     better if it is visible in plain sight, not hidden.

A third reason:

  * Sometimes there is an explicit way to code something and, alternatively,
    an optimized way. If a developer switches to the optimized way and then,
    much later, this optimized way cannot accommodate changed requirements,
    it is useful to switch back to the explicit way. But often the explicit
    way has been lost.
    Three examples:

      - Slow and optimized code. Cf. Knuth's proverb "Premature optimization
        is the root of all evil".

      - Explicit caching vs. @lru_cache.

      - In GLImport.__init__ the generic way of handling all properties.
        Dmitry was certainly proud of having found this generic handling,
        with the 'update' and 'update_key' methods. But now, how can it
        accommodate the desired handling of 'docbase' property [1]?
        Do you want to add more complexity to the generic handling?
        Or do you prefer to remove the generic handling altogether and
        get back to a more verbose, but more adaptable, explicit coding?

Bruno

[1] https://lists.gnu.org/archive/html/bug-gnulib/2024-04/msg00160.html