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 c
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 cou
>> 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 e
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
> 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 t
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
> 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
>
>> 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 represe
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 co
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
> 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 dictiona
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:
>
> 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
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 pro
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 t
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 li
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__() method
17 matches
Mail list logo
