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.

FWIW, you have a easy work-around.  Use repr(yourslice) as the dictionary key.

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.

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.

Guido, any thoughts?  I'm +0 on making slices hashable -- no real harm 
from doing it -- not much benefit either.

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.

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

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]}

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.

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.

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.

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[:].

This needs to stay rejected.  I'm unwilling to introduce special cases in the language just to support a peephole optimization.

Did Alexander ever present his case to python-dev?