Implementation of an lru_cache() decorator that ignores the first argument

[dn]

On 29/09/2022 07.22, Robert Latest via Python-list wrote:
...

> This is what I came up with. I'm quite happy with it so far.  Question: Am I
> being too clever? is it too complicated? Am I overlooking something that will
> come back and bite me later? Thanks for any comments!

Thank you for the chuckle: "Yes", you are clever; and "yes", this is
likely a bit too clever (IMHO).

The impression is that LRU will put something more-concrete, 'in front
of' SQLAlchemy - which is more abstract, and which is in-turn 'in front
of' the RDBMS (which is concrete...). Is this the code-smell making
one's nose suspicious?

The criticism is of SQLAlchemy. If the problem can't be solved with that
tool, perhaps it is not the right-tool-for-the-job...

Bias: With decades of SQL/RDBMS experience, it is easy to say, "drop the
tool".

+1 @Chris: depending upon how many transactions-between, it seems likely
find that the RDBMS will cache sufficiently, as SOP.

YMMV, ie there's only one way to find-out!
-- 
Regards,
=dn