How would the value equality operator deal with recursive objects?
class Foo:
def __init__(self):
self.foo = self
Seems to me that it would take atleast some special-casing to get
Foo() == Foo() to evalute to True in this case...
--
mvh Björn
BJörn Lindqvist wrote:
How would the value equality operator deal with recursive objects?
class Foo:
def __init__(self):
self.foo = self
Seems to me that it would take atleast some special-casing to get
Foo() == Foo() to evalute to True in this case...
This is sort-of
Martin v. Löwis [EMAIL PROTECTED] writes:
BJörn Lindqvist wrote:
How would the value equality operator deal with recursive objects?
class Foo:
def __init__(self):
self.foo = self
Seems to me that it would take atleast some special-casing to get
Foo() == Foo() to evalute to
On 7-nov-2005, at 23:34, Martin v. Löwis wrote:
BJörn Lindqvist wrote:
How would the value equality operator deal with recursive objects?
class Foo:
def __init__(self):
self.foo = self
Seems to me that it would take atleast some special-casing to get
Foo() == Foo() to
On 11/3/05, Josiah Carlson [EMAIL PROTECTED] wrote:
...
Right, but lists (dicts, tuples, etc.) are defined as containers, and
their comparison operation is defined on their contents. Objects are
not defined as containers in the general case, so defining comparisons
based on their contents
Noam Raphael [EMAIL PROTECTED] wrote:
On 11/3/05, Josiah Carlson [EMAIL PROTECTED] wrote:
To summarize, I think that value-based equality testing would usually
be what you want, and currently implementing it is a bit of a pain.
Actually, implementing value-based equality testing, when
On 11/5/05, Josiah Carlson [EMAIL PROTECTED] wrote:
...
1. It doesn't add complexity, or a new builtin.
It changes default behavior (which I specified as a portion of my
statement, which you quote.
And you are wrong, it adds complexity to the implementation of both
class instantiation and
Noam Raphael [EMAIL PROTECTED] wrote:
On 11/5/05, Josiah Carlson [EMAIL PROTECTED] wrote:
...
1. It doesn't add complexity, or a new builtin.
It changes default behavior (which I specified as a portion of my
statement, which you quote.
And you are wrong, it adds complexity to the
On 11/6/05, Josiah Carlson [EMAIL PROTECTED] wrote:
...
Sorry, I meant complexity to the Python user - it won't require him to
learn more in order to write programs in Python.
Ahh, but it does add complexity. Along with knowing __doc__, __slots__,
__metaclass__, __init__, __new__,
Noam Raphael [EMAIL PROTECTED] wrote:
On 11/6/05, Josiah Carlson [EMAIL PROTECTED] wrote:
...
Sorry, I meant complexity to the Python user - it won't require him to
learn more in order to write programs in Python.
You are right. But that's Python - I think that nobody knows all the
I think it should.
(I copy here messages from the thread about the default hash method.)
On 11/2/05, Michael Chermside [EMAIL PROTECTED] wrote:
Why not make the default __eq__ really compare the objects, that is,
their dicts and their slot-members?
Short answer: not the desired behavior.
I've looked for classes in my /usr/lib/python2.4 directory. I won't go
over all the 7346 classes that were found there, but let's see:
identity objects that will continue to work because they contain
other identity objects
SocketServer, and everything which inherits from
Noam Raphael [EMAIL PROTECTED] wrote:
On 11/2/05, Josiah Carlson [EMAIL PROTECTED] wrote:
I believe the current behavior of __eq__ is more desireable than
comparing contents, as this may result in undesireable behavior
(recursive compares on large nested objects are now slow, which used to
13 matches
Mail list logo
