proposal for slice hashing

[Chris Angelico]

On Tue, May 12, 2020 at 6:01 AM Will Bradshaw <defenastrator at gmail.com> 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