<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, 29 Jan 2016 at 10:14 Serhiy Storchaka <<a href="mailto:storchaka@gmail.com">storchaka@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">How to resolve distinguishing between documentation and implementation<br>
if current implementation is incorrect, but third-party code can<br>
implicitly depends on it?<br>
<br>
For example see issue26198. Currently buffer overflow of predefined<br>
buffer for "es#" and "et#" format units causes TypeError (with<br>
misleading message, but this is other story). The correct and<br>
*documented* exception is ValueError. User code can depend on current<br>
behavior, because TypeError is what is raised now for this type of<br>
errors, and this is what is raised for other types of errors. Unlikely<br>
authors of such code read the documentation, otherwise this issue would<br>
be reported earlier. On other hand, looks these format units are rarely<br>
used with predefined buffer (never in the stdlib since 3.5).<br>
<br>
I think it is obvious that the code in the development branch should be<br>
changed to produce documented and more logical exception. But what about<br>
bugfix releases? Changing the documentation would be misleading,<br>
changing the code can break existing code (unlikely, but).<br></blockquote><div><br></div><div>When the potential breakage is low, I would move to the more reasonable exception and add the appropriate note to the docs and What's New about how to port pre-existing code by either changing the exception caught or catching both exceptions until support < 3.6 can be dropped by the user. </div></div></div>