[Python-Dev] Intricacies of calling eq (original) (raw)

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