I strongly advise people interested in this topic to take a closer look
at the functionality that was added to address issue 2235. The don't
inherit __hash__ behaviour has been backported from 3.0 and broke a
bunch of code, but the naive fix of reverting to the 2.5 behaviour
proceeded to make
On Aug 30, 2008, at 2:41 PM, Ondrej Certik [EMAIL PROTECTED] wrote:
I strongly advise people interested in this topic to take a closer
look
at the functionality that was added to address issue 2235. The don't
inherit __hash__ behaviour has been backported from 3.0 and broke a
bunch of code,
Ondrej
Ondrej, a patch that improves the official docs would be welcome and still
potentially make 2.6/3.0
That'd be awesome. I need to finish my thesis in the next couple days,
so I'd welcome if anyone could just take it and put usefult things in.
I could get to do it the next week the
Ondrej Certik schrieb:
Ondrej
Ondrej, a patch that improves the official docs would be welcome and still
potentially make 2.6/3.0
That'd be awesome. I need to finish my thesis in the next couple days,
so I'd welcome if anyone could just take it and put usefult things in.
I could get to do
Hi Georg!
On Sat, Aug 30, 2008 at 11:09 PM, Georg Brandl [EMAIL PROTECTED] wrote:
Ondrej Certik schrieb:
Ondrej
Ondrej, a patch that improves the official docs would be welcome and still
potentially make 2.6/3.0
That'd be awesome. I need to finish my thesis in the next couple days,
so I'd
On 2008-08-28 21:31, Michael Foord wrote:
Hello all,
The documentation for __hash__ seems to be outdated. I'm happy to submit
a patch, so long as I am not misunderstanding something.
http://docs.python.org/dev/reference/datamodel.html#object.__hash__
The documentation states:
If a
Being hashable is a different from being usable as dictionary key.
Dictionaries perform the lookup based on the hash value, but will
then have to check for hash collisions based on an equal comparison.
If an object does not define an equal comparison, then it is not
usable as dictionary
M.-A. Lemburg wrote:
On 2008-08-28 21:31, Michael Foord wrote:
Hello all,
The documentation for __hash__ seems to be outdated. I'm happy to submit
a patch, so long as I am not misunderstanding something.
http://docs.python.org/dev/reference/datamodel.html#object.__hash__
The documentation
On 2008-08-29 13:03, Matt Giuca wrote:
Being hashable is a different from being usable as dictionary key.
Dictionaries perform the lookup based on the hash value, but will
then have to check for hash collisions based on an equal comparison.
If an object does not define an equal comparison,
It's probably a good idea to implement __hash__ for objects that
implement comparisons, but it won't always work and it is certainly
not needed, unless you intend to use them as dictionary keys.
So you're suggesting that we document something like.
Classes that represent mutable values
Note that only instances have the default hash value id(obj). This
is not true in general. Most types don't implement the tp_hash
slot and thus are not hashable. Indeed, mutable types should not
implement that slot unless they know what they're doing :-)
By instances you mean instances of
Matt Giuca wrote:
It's probably a good idea to implement __hash__ for objects that
implement comparisons, but it won't always work and it is certainly
not needed, unless you intend to use them as dictionary keys.
So you're suggesting that we
Hello all,
The documentation for __hash__ seems to be outdated. I'm happy to submit
a patch, so long as I am not misunderstanding something.
http://docs.python.org/dev/reference/datamodel.html#object.__hash__
The documentation states:
If a class does not define a __cmp__() or __eq__()
I'm not sure about the first but as for the __reversed__ we had a discussion
yesterday and it was indeed added in 2.4 (oddly, my 2.5 documentation has
this correct... )
--
Haikus are easy
Most make very little sense
Refrigerator
___
Python-Dev mailing
Michael Foord wrote:
This may have been true for old style classes, but as new style classes
inherit a default __hash__ from object - mutable objects *will* be
usable as dictionary keys (hashed on identity) *unless* they implement a
__hash__ method that raises a type error.
Shouldn't the
Jeff Hall wrote:
I'm not sure about the first but as for the __reversed__ we had a
discussion yesterday and it was indeed added in 2.4 (oddly, my 2.5
documentation has this correct... )
2.4 doc:
reversed( seq)
Return a reverse iterator. seq must be an object which supports the
sequence
This may have been true for old style classes, but as new style classes
inherit a default __hash__ from object - mutable objects *will* be usable as
dictionary keys (hashed on identity) *unless* they implement a __hash__
method that raises a type error.
I always thought this was a bug in
17 matches
Mail list logo
