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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4