[Python-3000] guessing a rule of thumb for methods on object

[Steven Bethard]

On 7/27/06, Guido van Rossum <guido at python.org> wrote:
> On 7/27/06, Steven Bethard <steven.bethard at gmail.com> wrote:
> > [1] It might get you something for __hash__() if object.__hash__() is
> > not removed, but that debate still seems to be in progress and I'm not
> > sure it's worth the added complexity to handle one special case.
>
> FWIW, I don't believe your "solution" to remove __hash__ and supply an
> id-dict will work. Unless someone else supports it, it's off the table
> as far as I'm concerned. Sorry, I can't exactly explain why, but my
> gut tells me that.

I thought about this for a while, and I think maybe a good rule of
thumb (and something like what Python seems to follow) is: "If it's
there's an obvious default implementation of a protocol that would be
generally useful, it should go on all objects."

So, for example, the __hash__ method has a default implementation
that's generally useful if you want to map unique objects to other
values.  So it makes sense to have the object.__hash__ method. And for
the same reason, it also makes sense to have something like an
object.__eq__ method[1].

OTOH, something like __call__ or __iter__ doesn't have an obvious
default implementation -- e.g. what would it mean to call an integer?
-- so those don't go on object.  And dropping object.__cmp__[2] for
Python 3000 makes sense because there isn't really an obvious default
implementation -- there's no real reason why ``['a'] < 'a' < ('a',)``
ought to be True.

STeVe

[1] I know that since in Python 2.X some things aren't children of
object, this is actually implemented in the C comparisons, but it's
useful to think of it this way. Are there any plans for Python 3000 to
move this behavior into object.__eq__?

[2] See note 1. Yes, I know object.__cmp__ doesn't actually exist.
-- 
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
        --- Bucky Katt, Get Fuzzy