[Python-Dev] Inheritance vs composition in backcompat (PEP521)

Nick Coghlan ncoghlan at gmail.com
Wed Oct 4 09:04:42 EDT 2017

On 4 October 2017 at 22:45, Koos Zevenhoven <k7hoven at gmail.com> wrote:
> On Wed, Oct 4, 2017 at 3:33 PM, Nick Coghlan <ncoghlan at 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).


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-Dev mailing list