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. With this
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
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
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
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
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 still
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
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().
Making
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
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
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 be
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.
It's
(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
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 into
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, 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 objects
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 work with
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 this
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 terms of
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
types.
21 matches
Mail list logo
