[Python-Dev] Intricacies of calling __eq__

[Thomas Wouters]

On Wed, Mar 19, 2014 at 6:26 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:

> On Wed, 19 Mar 2014 15:21:16 +0200
> Maciej Fijalkowski <fijall at gmail.com> wrote:
>
> > On Wed, Mar 19, 2014 at 3:17 PM, Antoine Pitrou <solipsis at pitrou.net>
> wrote:
> > > On Wed, 19 Mar 2014 15:09:04 +0200
> > > Maciej Fijalkowski <fijall at gmail.com> wrote:
> > >>
> > >> I would like to point out that instructing people does not really
> > >> work. Besides, other examples like this:
> > >>
> > >> if d[x] >= 3:
> > >>    d[x] += 1 don't really work.
> > >
> > > That's a good point. But then, perhaps PyPy should analyze the __eq__
> > > method and decide whether it's likely to have side effects or not (the
> > > answer can be hard-coded for built-in types such as str).
> > >
> > > Regards
> > >
> > > Antoine.
> >
> > Ok. But then how is it valid to have "is" fast-path?
>
> What do you mean?
>

He means you're being unrealistically pedantic :) The number of calls to
__eq__ is _already_ unpredictable, since (as Mark Shannon said) it depends
among other things on the hashing algorithm and the size of the dict. If we
were serious about not changing these kinds of aspects between Python
implementations, we certainly shouldn't be changing them between versions
of the same Python implementation -- and so we would be banned from ever
changing the details of the dict type. Absurd.

-- 
Thomas Wouters <thomas at python.org>

Hi! I'm an email virus! Think twice before sending your email to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140319/5249d0ff/attachment.html>