Though I tried to submit a (pre-) PEP in the proper form through the proper
channels, it has disappeared into the ether.
In building a class that supports Python's slicing interface,
http://groups.google.com/group/comp.lang.python/msg/8f35464483aa7d7b
I encountered a Python bug, which, upon
At 07:12 PM 11/6/2005 -0500, Phillip J. Eby wrote:
>At 01:29 PM 11/6/2005 -0800, Guido van Rossum wrote:
> >On 11/6/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > > At 12:58 PM 11/6/2005 -0800, Guido van Rossum wrote:
> > > >The main way this breaks down is when comparing objects of different
>
At 01:29 PM 11/6/2005 -0800, Guido van Rossum wrote:
>On 11/6/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > At 12:58 PM 11/6/2005 -0800, Guido van Rossum wrote:
> > >The main way this breaks down is when comparing objects of different
> > >types. While most comparisons typically are defined in
John Williams <[EMAIL PROTECTED]> wrote:
>
> (This is kind of on a tangent to the original discussion, but I don't
> want to create yet another subject line about object comparisons.)
>
> Lately I've found that virtually all my implementations of __cmp__,
> __hash__, etc. can be factored into
On 11/6/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 11/6/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > When I use this pattern, I often just include the object's type in the
> > key. (I call it the 'hashcmp' value, but otherwise it's the same pattern.)
>
> But how do you make that wor
On 11/6/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 12:58 PM 11/6/2005 -0800, Guido van Rossum wrote:
> >The main way this breaks down is when comparing objects of different
> >types. While most comparisons typically are defined in terms of
> >comparisons on simpler or contained objects, two
At 12:58 PM 11/6/2005 -0800, Guido van Rossum wrote:
>The main way this breaks down is when comparing objects of different
>types. While most comparisons typically are defined in terms of
>comparisons on simpler or contained objects, two objects of different
>types that happen to have the same "key
On 11/6/05, John Williams <[EMAIL PROTECTED]> wrote:
> (This is kind of on a tangent to the original discussion, but I don't
> want to create yet another subject line about object comparisons.)
>
> Lately I've found that virtually all my implementations of __cmp__,
> __hash__, etc. can be factored
(This is kind of on a tangent to the original discussion, but I don't
want to create yet another subject line about object comparisons.)
Lately I've found that virtually all my implementations of __cmp__,
__hash__, etc. can be factored into this form inspired by the "key"
parameter to the built
Guido van Rossum wrote:
> On 11/6/05, Jim Fulton <[EMAIL PROTECTED]> wrote:
>
...
> Except that I really don't think that there's anything wrong with a
> default __eq__ that uses object identity. As Martin pointed out, it's
> just too weird that an object wouldn't be considered equal to itself.
>
On 11/6/05, Jim Fulton <[EMAIL PROTECTED]> wrote:
> IMO, the provision of defaults for hash, eq and other comparisons
> was a mistake.
I agree with you for 66%. Default hash and inequalities were a
mistake. But I wouldn't want to do without a default ==/!=
implementation (and of course it should b
The recent discussion about what the default hash and equality comparisons
should do makes me want to chime in.
IMO, the provision of defaults for hash, eq and other comparisons
was a mistake. I'm especially sensitive to this because I do a lot
of work with persistent data that outlives program
Noam Raphael wrote:
> The alternative is to drop the __hash__ method of user-defined classes
> (as Guido already decided to do), and to make the default __eq__
> method compare the two objects' __dict__ and slot members.
The question then is what hash(x) would do. It seems that you expect
it then
13 matches
Mail list logo
