Hi Noam,
On Sun, Nov 27, 2005 at 09:04:25PM +0200, Noam Raphael wrote:
> No, I meant real programming examples. My theory is that most
> user-defined classes have a "value", and those that don't are related
> to I/O, in some sort of a broad definition of the term. I may be
> wrong, so I ask for co
On 11/27/05, Samuele Pedroni <[EMAIL PROTECTED]> wrote:
> well, this still belongs to comp.lang.python.
...
> not if you think python-dev is a forum for such discussions
> on OO thinking vs other paradigms.
Perhaps my style made it look like a discussion on OO thinking vs
other paradigms, but my c
On 11/27/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Noam Raphael wrote:
> > I would greatly appreciate repliers that find a tiny bit of reason in
> > what I said (even if they don't agree), and not deny it all as a
> > complete load of rubbish.
>
> I don't understand what your message is
Adam Olsen wrote:
> On 11/26/05, Noam Raphael <[EMAIL PROTECTED]> wrote:
>> [...stuff about using Ref() for identity dictionaries...]
>
> I too have thought along these lines, but I went one step further.
> There is an existing function that could be modified to produce Ref
> objects: id().
>
>
On 11/26/05, Noam Raphael <[EMAIL PROTECTED]> wrote:
> [...stuff about using Ref() for identity dictionaries...]
I too have thought along these lines, but I went one step further.
There is an existing function that could be modified to produce Ref
objects: id().
Making id() into a type allows it
Noam Raphael wrote:
> Three weeks ago, I read this and thought, "well, you have two options
> for a default comparison, one based on identity and one on value, both
> are useful sometimes and Guido prefers identity, and it's OK." But
> today I understood that I still think otherwise.
>
well, this
Noam Raphael wrote:
> I would greatly appreciate repliers that find a tiny bit of reason in
> what I said (even if they don't agree), and not deny it all as a
> complete load of rubbish.
I don't understand what your message is. With this posting, did you
suggest that somebody does something spe
Three weeks ago, I read this and thought, "well, you have two options
for a default comparison, one based on identity and one on value, both
are useful sometimes and Guido prefers identity, and it's OK." But
today I understood that I still think otherwise.
In two sentences: sometimes you wish to c
Two more thoughts in this thread.
(1) The "key" idiom is a great pattern but I don't think it would work
well to make it a standard language API.
(2) I'm changing my mind about the default hash().
The original default hash() (which would raise TypeError if __eq__ was
overridden but __hash__ was
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
19 matches
Mail list logo
