On Tue, May 12, 2020 at 6:01 AM Will Bradshaw <[email protected]> wrote:
> The only options as of now are:
> 1. use 3 layers of wrappers to pack the slices into a custom type that
> supports hashing pass this mangled version of the arguments through lru_cache
> wrapper into a function that reverses the process of the first wrapper and
> passes through to the underlying implementation. (see below "code for
> workaround" as example)
> - This is kinda jank and arguably slow. Though in my case the cost of
> the calculation operation dwarfs this cost by an several orders of magnitude.
> - mapping may be unreliable and is a rather long and impenetrable mess.
> 2. implementing my own custom caching for this situation which does not
> scale well and is a heck of a lot of work.
> 3. implement a special case for slices in the lru_cache function.
> However, this is just moving the problem into the functools library.
>
4. Implement __getitem__ as a wrapper around a caching lookup function
that simply takes the three arguments.
def __getitem__(self, slice):
return generate_values(slice.start, slice.stop, slice.step)
@lru_cache
def generate_values(start, stop, step):
...
Not sure if this makes it easy enough to not worry about the hashability.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
