<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><span style="font-family:arial,sans-serif">On Wed, Oct 4, 2017 at 4:04 PM, Nick Coghlan </span><span dir="ltr" style="font-family:arial,sans-serif"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span><span style="font-family:arial,sans-serif"> wrote:</span><br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 4 October 2017 at 22:45, Koos Zevenhoven <<a href="mailto:k7hoven@gmail.com">k7hoven@gmail.com</a>> wrote:<br>
> On Wed, Oct 4, 2017 at 3:33 PM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>
</span><span class="">>> That's not a backwards compatibility problem, because the only way to<br>
>> encounter it is to update your code to rely on the new extended<br>
>> protocol - your *existing* code will continue to work fine, since<br>
>> that, by definition, can't be relying on the new protocol extension.<br>
>><br>
><br>
> No, not all code is "your" code. Clearly this is not a well-known problem.<br>
> This is a backwards-compatibility problem for the author of the wrappeR, not<br>
> for the author of the wrappeD object.<br>
<br>
</span>No, you're misusing the phrase "backwards compatibility", and<br>
confusing it with "feature enablement".<br>
<br>
Preserving backwards compatibility just means "existing code and<br>
functionality don't break". It has nothing to do with whether or not<br>
other support libraries and frameworks might need to change in order<br>
to enable full access to a new language feature.<br>
<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace">​It's not about full access to a new language feature. It's about the wrappeR promising it can wrap any ​context manager, which it then no longer can. If the __suspend__ and __resume__ methods are ignored, that is not about "not having full access to a new feature" — that's broken code. The error message you get (if any) may not contain any hint of what went wrong.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Take the length hint protocol defined in PEP 424 for example: that<br>
extended the iterator protocol to include a new optional<br>
__length_hint__ method, such that container constructors can make a<br>
more reasonable guess as to how much space they should pre-allocate<br>
when being initialised from an iterator or iterable rather than<br>
another container.<br>
<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace">​This is slightly similar, but not really. Not using __length_hint__ does not affect the correctness of code.</div><div class="gmail_default" style="font-family:monospace,monospace"><span style="font-family:arial,sans-serif"> </span><br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That protocol means that many container wrappers break the<br>
optimisation. That's not a compatibility problem, it just means those<br>
wrappers don't support the feature, and it would potentially be a<br>
useful enhancement if they did.<br>
<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace">​Again, ignoring __length_hint__ does not lead to broken code, so that just means the wrapper is as slow or as fast as it was before.</div></div><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace">​So I still think it's an issue for the author of the wrapper to fix––even if just by documenting that the wrapper does not support the new protocol members. But that would not be necessary if the wrapper uses inheritance. </div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">(Of course there may be another reason to not use inheritance, but just overriding two methods seems like a good case for inheritance.).</div><div class="gmail_default" style="font-family:monospace,monospace">​</div><div class="gmail_default" style="font-family:monospace,monospace">​This discussion seems pretty pointless by now. It's true that *some* code needs to change for this to be a problem. Updating only the Python version does not break a codebase if libraries aren't updated, and even then, breakage is not very likely, I suppose. </div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">It all depends on the kind of change that is made. For __length_hint__, you only risk not getting the performance improvement. For __suspend__ and __resume__, there's a small chance of problems. For some other change, it might be even riskier. But this is definitely not the most dangerous type of compatibility issue.</div></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">––Koos</div></div><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">+ Koos Zevenhoven + <a href="http://twitter.com/k7hoven" target="_blank">http://twitter.com/k7hoven</a> +</div>
</div></div>