slice cannot be hashed which make some operations significantly more annoying. see https://groups.google.com/forum/#!topic/comp.lang.python/SvhkWwSDeIw

Please re-upload the patch file as an uncompressed text file, as it is quite difficult for many people to view zip files in their browser.

This is a reasonable use case.

+1 for making slice() hashable.

Will, you're welcome to submit a PR. If not, I'm sure someone else would be happy to scoop this up :-)

Would be happy to help with this. Sent a PR soon ;)

I think slices were explicitly made not hashable to avoid issues to avoid issues with dictionaries, see discussion at https://mail.python.org/pipermail/python-list/2001-March/076101.html and bpo-408326.

The commit that did this is a1351fb

Is this not needed anymore? Wouldn't this need to be discussed on python-ideas?

Guido, what are your thoughts on this proposal?

On the one hand, the OP has a legitimate use case:

I have an object that presents itself as a multidimensional array in the numpy style but is computes it's values on _getitem_ calls as it represents an infinite field of numbers. However this operation is expensive. In many cases the same slice of the field will be needed repeatedly. This lends itself to using an lru cache on _getitem_() however this does not work as slices cannot be stored in the dictionary key used for the lru_cache.

On the other hand, slice literals for mappings are a mixed bag, possibly useful in some cases, possibly surprising in others:

>>> d = {'hello': 1, 'world': 2}
>>> d['hello': 'world']
Traceback:
   ...
KeyError:  slice('hello', 'world', None)  

I like the idea of being able to cache array or sequence slices but worry about opening a can of worms for the general case.

I think this is fine. The "danger" of d[a:b] seems overstated, it produces a clear KeyError.

@gvanrossum Thanks for the looking at this.

Note that this still needs a “what’s new” entry, since it is a new feature and might even trip some folks up (see the test changes needed).