proposal for slice hashing

[Will Bradshaw]

On Monday, May 11, 2020 at 4:10:56 PM UTC-4, Chris Angelico wrote:
> 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

does not work in the case of multi dimensional __getitem__ calls in the numpy style which happens to be my case as the number of dimensions in the indexes changes by case and all of the following are supported for each axis: slice, array of indexes, int index, and other custom index object types which I am hesitant to disclose)