slice not hashable

[WillBradshaw]

BPO	40603
Nosy	@rhettinger, @stevendaprano, @remilapeyre, @isdanni
Files	patches.zip: patch to add slicing functionality to slices

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2020-05-12.01:23:39.253>
labels = ['interpreter-core', 'easy', 'type-feature', '3.9']
title = 'slice not hashable'
updated_at = <Date 2020-05-12.08:34:03.335>
user = 'https://bugs.python.org/WillBradshaw'

bugs.python.org fields:

activity = <Date 2020-05-12.08:34:03.335>
actor = 'remi.lapeyre'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2020-05-12.01:23:39.253>
creator = 'Will Bradshaw'
dependencies = []
files = ['49149']
hgrepos = []
issue_num = 40603
keywords = ['easy (C)']
message_count = 5.0
messages = ['368693', '368694', '368696', '368700', '368708']
nosy_count = 5.0
nosy_names = ['rhettinger', 'steven.daprano', 'remi.lapeyre', 'isdanni', 'Will Bradshaw']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue40603'
versions = ['Python 3.9']

Linked PRs

• GH-84783: Make the slice object hashable #101264
• GH-84783: Document GH-101264 (Make the slice object hashable) in What's New. #102548
• GH-84783: Mention Author for GH-101264 (make slices hashable) #103146

[WillBradshaw]

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

[stevendaprano]

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.

[rhettinger]

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 :-)

[isdanni]

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

[remilapeyre]

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?

[rhettinger]

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.

[gvanrossum]

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

[rhettinger]

@gvanrossum Thanks for the looking at this.

[gvanrossum]

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).

[Yhg1s]

GH-102548 adds the missing What's New entry.

[hauntsaninja]

What's New was merged, so I think this can be closed

[asmeurer]

Thank you for fixing this.

For anyone who was wanting hashable slices, my library ndindex may be of interest. It has a hashable Slice object but it also does a lot more like slice arithmetic which may be useful for a lot of the use cases described here.