More than you ever wanted to know about objects

[Mike Meyer]

aleax at mail.comcast.net (Alex Martelli) writes:
> Steve Holden <steve at holdenweb.com> wrote:
>    ...
>> > 3. If two objects are equal with "==", does that
>> >   mean their values are the same?
>> Almost universally, yes, although if you know enough about how the 
>> interpreter works "under the hood" you can define the response of 
>> instances of your own classes to the "==" operator (by defining their
>> __eq__ method), and even define a class whose instances aren't equal to
>> anything, even to themselves!
> Hmmm... now this may be just be, but I'm quite vary of saying that,
> since 1 == 1.0 == 1.0+0j, those three objects's values "are the same".

For even more fun, consider 1.0 == 1 == decimal.Decimal('1.0').

> "Are equal", sure.  But I intuitively see "being the same" as a stronger
> condition than "being equal".

When you say "being the same", I think "identity". But that's not
right either.

> In mathematics, 1 is not "the same" as 1.0 -- there exists a natural
> morphism of integers into reals that _maps_ 1 to 1.0, but they're still
> NOT "the same" thing.

But what makes them different isn't attached to *them* - it comes with
the group/field they are part of. If I give you a mathematical 1 in
isolation, you can't tell if it's a real, an integer, a counting
number, or a member of Z-sub-n.

> ((I don't think this violates the "introduce no complexity that doesn't
> help understanding" rule -- I think the 1==1.0 case is important!))

I do too. But I also think that Python's number types are somewhat
dodgy, and we might be better off if we ignore them for now. After we
get things straightened out for the other types, we can worry about
numbers.


        <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.