classification
Title: slice type is unhashable
Type: enhancement Stage:
Components: Interpreter Core Versions: Python 2.5
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: rhettinger Nosy List: belopolsky, exarkun, gvanrossum, lpd, rhettinger
Priority: normal Keywords:

Created on 2007-06-08 02:30 by lpd, last changed 2010-08-22 01:24 by gvanrossum. This issue is now closed.

Messages (14)
msg32255 - (view) Author: L. Peter Deutsch (lpd) Date: 2007-06-08 02:30
Patch # 408326 is a "bug fix" that makes slice objects comparable but explicitly NOT hashable.  I don't understand why Guido thinks this is the right behavior for them: they are immutable, have well-defined state, do not include references to mutable objects, and can be compared property for equality.  Why shouldn't they be usable as dictionary keys?  I have an application that really would like them to be usable as such.  I know I can define a class Slice of my own .. but that seems so silly.
msg32256 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2007-06-08 05:24
FWIW, you have a easy work-around.  Use repr(yourslice) as the dictionary key.
msg32257 - (view) Author: L. Peter Deutsch (lpd) Date: 2007-06-08 05:36
I could probably live with that.  However, there are other kinds of objects being used as keys in the same dictionary, and I can't just repr() them all, because it is not true that a == b implies repr(a) == repr(b).  (E.g., a = 3, b = 3.0.)

Practicalities aside, it just seems silly to me that a simple type like slice should have all the prerequisites for being hashable and yet isn't, especially when much more complex types like methods are both comparable and hashable.
msg63375 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2008-03-08 00:55
Patch # 408326 was designed to make assignment to d[:] an error where d 
is a dictionary.  See discussion starting at http://mail.python.org/pipermail/python-list/2001-March/072078.html .

I think the only reason slice objects need to be comparable is only to 
suppress inheritance of the default hash from object.

This RFE is ripe to be rejected.  Slice objects are really meant to be 
internal structures and not passed around in the user's code.  You can 
always use tuples instead of slices and convert the to slices with 
slice(*t) when needed.
msg63379 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2008-03-08 03:02
Guido, any thoughts?  I'm +0 on making slices hashable -- no real harm 
from doing it -- not much benefit either.
msg63380 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2008-03-08 03:10
In case I did not make my position clear in my previous post, I am -1 on 
this RFE.  x[:] should mean slicing, not getitem.
msg63381 - (view) Author: Jean-Paul Calderone (exarkun) * (Python committer) Date: 2008-03-08 03:15
> Slice objects are really meant to be internal structures and not
passed around in the user's code. 

I don't know what they're "meant" to be, but they're certainly not
internal.  If you implement __getitem__, __setitem__, or __delitem__,
then chances are Python is going to be passing slices to your code. 
That doesn't sound internal to me.

Having hashable slices is nice.  The repr() workaround has a major
drawback in that it makes it difficult to use the extremely useful
"indices" method of the slice type.
msg63384 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2008-03-08 05:29
Alexander nailed my motivation.

Have the proponents for this change really thought through that making
slices hashable means that henceforth this code will work?

d = {}
d[:] = [1, 2, 3]      # surprise here
print d               # prints {slice(None, None, None): [1, 2, 3]}
msg63400 - (view) Author: Jean-Paul Calderone (exarkun) * (Python committer) Date: 2008-03-08 13:57
I don't see the ability to use a slice as a dict key as particularly
more surprising than the ability to use ints as dict keys.  Someone who
doesn't understand how dicts work can use either of these features to
write broken programs.

I have thought about that example and it's precisely the kind of thing I
would like to work.  The behavior is consistent with that of using any
other immutable value as a key.  I don't have a use case right now (and
by admitting so may be dooming this change - but L. Peter Deutsch has
one, I think) but there's no way I would ever benefit from the current
behavior, whereas I _might_ be able to do something useful with the
proposed behavior.
msg63402 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2008-03-08 14:12
Note that L[:] and L[:] = [] are well-known idioms for making a copy of 
a list and emptying the list respectively. (For dictionaries we have 
D.copy() and D.clear().) Someone looking at x[:] or x[:] = [] should 
immediately recognize a list copy or clear operation.  Having to think 
of whether x may be a dictionary would make such code very confusing.
msg64418 - (view) Author: L. Peter Deutsch (lpd) Date: 2008-03-24 16:37
Having now read messages 63380 and 63384, I agree with them: I would
have withdrawn my proposal if it hadn't gotten rejected first. I do have
a use case, but the workaround is pretty easy.
msg64425 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2008-03-24 17:29
I hate to flip-flop like this, but please consider my new
arguments at issue2268.  In short, slices being unhashable
prevents storing them in the code object's const dictionary
and thus prevents optimizing code involving const slices.

Unless I hear strong opposition from the bug tracker forum,
I plan to present some ideas on python-dev on how to make
slices hashable while not enabling d[:].
msg114630 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2010-08-22 01:20
This needs to stay rejected.  I'm unwilling to introduce special cases in the language just to support a peephole optimization.
msg114632 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2010-08-22 01:24
Did Alexander ever present his case to python-dev?
History
Date User Action Args
2010-08-22 01:24:17gvanrossumsetmessages: + msg114632
2010-08-22 01:20:11rhettingersetassignee: gvanrossum -> rhettinger
messages: + msg114630
2008-03-24 17:29:20belopolskysetmessages: + msg64425
2008-03-24 16:37:16lpdsetmessages: + msg64418
2008-03-08 18:24:29rhettingersetstatus: open -> closed
resolution: rejected
2008-03-08 14:12:11belopolskysetmessages: + msg63402
2008-03-08 13:57:56exarkunsetmessages: + msg63400
2008-03-08 05:29:57gvanrossumsetmessages: + msg63384
2008-03-08 03:15:41exarkunsetnosy: + exarkun
messages: + msg63381
2008-03-08 03:10:41belopolskysetmessages: + msg63380
2008-03-08 03:02:50rhettingersetassignee: gvanrossum
messages: + msg63379
nosy: + gvanrossum
2008-03-08 00:55:19belopolskysettype: enhancement
messages: + msg63375
nosy: + belopolsky
2007-06-08 02:30:16lpdcreate