«

On Wed, Sep 03, 2003 at 07:35:31AM +1000, Delaney, Timothy C (Timothy) wrote:
> > From: Terry Reedy [private.php?do=newpm&u=]
> >
> > "Stefan Fleiter" <> wrote in message
> > news:bj2nv5$hna$...
> >
> > > under Python 2.2.2:
> > >
> > > >>> s = slice(None,5,None)
> > > >>> hash(s)
> > > Traceback (most recent call last):
> > > File "<stdin>", line 1, in ?
> > > TypeError: unhashable type
> > > >>> s.__hash__()
> > > 136775584
> > >
> > > Can anybody explain this?
> >
> > It looks like a bug. Extended slices were added for use by Numerical
> > Python. It may never have tried to hash them or only done so only
> > through the C equivavlent of s.__hash__. Extended slicing of
> > sequences was, I believe, only added in 2.3.
>
> Looks like a bug to me too. Stefan, please raise a bug report on Sourceforge (or it will get lost). Preferably add a patch and test suite
>
> Tim Delaney

No, it's apparently deliberate that slices don't hash (so that
{}[1:2] raises an error). I think that slice(None).__hash__ is from
object.__hash__, but this is rightfully(?) ignored by PyObject_Hash()
which looks at tp_hash (NULL for slice objects) and tp_compare (non-NULL
for slice objects) with the result that the object is treated as
unhashable.

Jeff

Hi,

Jeff Epler wrote:

> No, it's apparently deliberate that slices don't hash (so that
> {}[1:2] raises an error). I think that slice(None).__hash__ is from
> object.__hash__, but this is rightfully(?) ignored by PyObject_Hash()
> which looks at tp_hash (NULL for slice objects) and tp_compare (non-NULL
> for slice objects) with the result that the object is treated as
> unhashable.

So, should I write a bugreport or not?
Are you sure it is "rightfully ignored" or not?

Somewhat puzzled,
Stefan

Jeff Epler <> writes:

> On Wed, Sep 03, 2003 at 07:35:31AM +1000, Delaney, Timothy C (Timothy) wrote:
> > > From: Terry Reedy [private.php?do=newpm&u=]
> > >
> > > "Stefan Fleiter" <> wrote in message
> > > news:bj2nv5$hna$...
> > >
> > > > under Python 2.2.2:
> > > >
> > > > >>> s = slice(None,5,None)
> > > > >>> hash(s)
> > > > Traceback (most recent call last):
> > > > File "<stdin>", line 1, in ?
> > > > TypeError: unhashable type
> > > > >>> s.__hash__()
> > > > 136775584
> > > >
> > > > Can anybody explain this?
> > >
> > > It looks like a bug. Extended slices were added for use by Numerical
> > > Python. It may never have tried to hash them or only done so only
> > > through the C equivavlent of s.__hash__. Extended slicing of
> > > sequences was, I believe, only added in 2.3.
> >
> > Looks like a bug to me too. Stefan, please raise a bug report on Sourceforge (or it will get lost). Preferably add a patch and test suite
> >
> > Tim Delaney
>
> No, it's apparently deliberate that slices don't hash (so that
> {}[1:2] raises an error). I think that slice(None).__hash__ is from
> object.__hash__, but this is rightfully(?) ignored by PyObject_Hash()
> which looks at tp_hash (NULL for slice objects) and tp_compare (non-NULL
> for slice objects) with the result that the object is treated as
> unhashable.

That's odd. I would have expected PyType_Ready to copy the tp_hash
method down from PyObjectType.tp_hash to PySliceType.tp_hash. Of
course, I haven't read the code for PyType_Ready particularly
recently, and don't know if it's ever called on PySliceType...

Cheers,
mwh

--
I'm not sure that the ability to create routing diagrams
similar to pretzels with mad cow disease is actually a
marketable skill. -- Steve Levin
-- http://home.xnet.com/~raven/Sysadmin/ASR.Quotes.html

On Wed, Sep 03, 2003 at 11:50:41AM +0200, Stefan Fleiter wrote:
> Hi,
>
> Jeff Epler wrote:
>
> >No, it's apparently deliberate that slices don't hash (so that
> >{}[1:2] raises an error). I think that slice(None).__hash__ is from
> >object.__hash__, but this is rightfully(?) ignored by PyObject_Hash()
> >which looks at tp_hash (NULL for slice objects) and tp_compare (non-NULL
> >for slice objects) with the result that the object is treated as
> >unhashable.
>
> So, should I write a bugreport or not?
> Are you sure it is "rightfully ignored" or not?

I'm sure that multiple python-list/c.l.python readers claim it is a feature
that hash(slice(None)) raises an exception.

http://google.com/groups?threadm=mai...t%40python.org

Jeff

"Stefan Fleiter" <> wrote in message
news:bj4dhh$24s$...
> So, should I write a bugreport or not?
> Are you sure it is "rightfully ignored" or not?

At worse, a bug report such 'Slice hashing: behavior or doc bug?'
would be closed by someone in the know as 'Not a bug'. If it is not a
behavior bug, then docs could use slight modification, and so a bug
report would be appropriate anyway.

Ref Manual 5.3.3 Slicings says nothing about hashability. If not
hashable, in spite of being mutable, "Slices are not hashable" could
be added at end.

Ref Manual 3.3.1 Basic customization, __hash__( self) entry says
"Called for the key object for dictionary operations, and by the
built-in function hash() "

This implies to me that if there is a __hash__() method, then hash()
will call it. If not true, then a 'maybe' could be added.

Lif Maual 2.1 Built-in Functions, hash( object) says only
"Return the hash value of the object (if it has one)."
If having __hash__() does not mean 'has one', then what does.

Feel free to copy if you do file.

Terry J. Reedy