On 4 October 2017 at 22:45, Koos Zevenhoven <k7ho...@gmail.com> wrote: > On Wed, Oct 4, 2017 at 3:33 PM, Nick Coghlan <ncogh...@gmail.com> wrote: >> That's not a backwards compatibility problem, because the only way to >> encounter it is to update your code to rely on the new extended >> protocol - your *existing* code will continue to work fine, since >> that, by definition, can't be relying on the new protocol extension. >> > > No, not all code is "your" code. Clearly this is not a well-known problem. > This is a backwards-compatibility problem for the author of the wrappeR, not > for the author of the wrappeD object.
No, you're misusing the phrase "backwards compatibility", and confusing it with "feature enablement". Preserving backwards compatibility just means "existing code and functionality don't break". It has nothing to do with whether or not other support libraries and frameworks might need to change in order to enable full access to a new language feature. Take the length hint protocol defined in PEP 424 for example: that extended the iterator protocol to include a new optional __length_hint__ method, such that container constructors can make a more reasonable guess as to how much space they should pre-allocate when being initialised from an iterator or iterable rather than another container. That protocol means that many container wrappers break the optimisation. That's not a compatibility problem, it just means those wrappers don't support the feature, and it would potentially be a useful enhancement if they did. Similarly, when context managers were added, folks needed to add appropriate implementations of the protocol in order to be able to actually make use of the feature. If a library didn't support it natively, then they either needed to write their own context manager, or else contribute an enhancement to that library. This pattern applies whenever a new protocol is added or an existing protocol is extended: whether or not you can actually rely on the new feature will depend on whether or not all your dependencies also support it. The best case scenarios are those where we can enable a new feature in a few key standard library APIs, and then most third party APIs will transparently pick up the new behaviour (e.g. as we did for the fspath protocol). However, even in situations like that, there may still be other code that makes no longer correct assumptions, and blocks access to the new feature (e.g. by including an explicit isinstance check). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
