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
Why 'identity' objects can't define:
def __getKey__(self):
return Key(self, id(self))
Then they would act as usually, while value object can define
def __getKey__(self):
return Key(self, self.i, self.j, self.a[1])
(Key is an abstraction to handle subclassing)
Of course,
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
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
21 matches
Mail list logo
