Home Original page

[Python-Dev] Intricacies of calling __eq__

Stephen J. Turnbull stephen at xemacs.org
Wed Mar 19 17:35:53 CET 2014 
Kevin Modzelewski writes:

 > Sorry, I definitely didn't mean to imply that this kind of
 > optimization is valid on arbitrary subscript expressions; I thought
 > we had restricted ourselves to talking about builtin dicts.

Ah, maybe so -- Maciej made that clear later for PyPy.  My bad.  (With
the caveat that IIUC Python does not include the technology for
detecting for sure that you've got a builtin dict -- a given instance
might even be monkey-patched.)

 > If we do, I think this becomes a discussion about what subset of
 > the semantics of CPython's builtins are language-specified vs
 > implementation-dependent; my argument is that just because
 > something results in an observable behavioral difference doesn't
 > necessarily mean that it's a change in language semantics, if it's
 > just a change in the implementation-dependent behavior.

I think you're wrong there.  Python makes very strong guarantees of
backward compatibility; there really isn't that much left to be
implementation-dependent once a feature has been introduced and
released.

Things are a lot more flexible at the introduction of a feature (eg,
the decorator example where the specification of the feature clearly
involves evaluating an expression twice, but the implementation
doesn't).  Although I doubt anybody considers that a big deal (and if
they did, they'd fix the documentation).  But I don't think a *change*
in that would be consided "not a change in language semantics."

That doesn't mean such a change wouldn't be allowed in a 3.x.0
release.  Just that it would be called a change.
More information about the Python-Dev mailing list