> > 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 fea
Hi Bruno,
On 4/16/24 8:47 AM, Bruno Haible wrote:
> Yes, they _can_ be made static, but they can also be left as-is. And so,
> as a developer, you start to spend time considering whether to make a
> function static or not. That time is not well spent.
We are in agreement there. PyCharm gives hint
Hi Collin,
> I don't necessarily disagree with your point about the use of
> higher-order functions. I found decorator functions really confusing
> when I first started using Python
;-)
> I make an exception to this rule for decorators that are a part of the
> Python language or standard library
Hi Bruno,
On 4/15/24 11:24 AM, Bruno Haible wrote:
> It's better to not do it, and keep the code as-is.
That is fine with me. Though I will offer my perspective on some of
your reasonings. Similar considerations to a previous thread [1].
> * As I already mentioned, it's good to keep the code u
Hi Collin,
> I was looking at the documentation for the Python standard library
> yesterday and discovered the 'lru_cache()' function [1]. ...
>
>if 'makefile-unconditional' not in self.cache:
># do work and then save it
>self.cache['makefile-unconditional'] = resu
I was looking at the documentation for the Python standard library
yesterday and discovered the 'lru_cache()' function [1]. Python 3.9
defines 'cache()' to be 'lru_cache(maxsize=None)' [2]. This is a
simple cache doesn't require a list and keeping track of size for LRU
replacements [3].
I was curi
