[Python-Dev] Bugfix releases should not change APIs (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Sat May 29 05:41:33 CEST 2010

On 29/05/10 09:03, Terry Reedy wrote:

After filing http://bugs.python.org/issue8840 I was rather shocked to be told that the code-breaking and policy-violating change was intentional because being 'more consistent with other file-handling APIs out there' was somehow more important than consistency within version releases. It also seems to me that discussion of code-breaking API changes like this should involve more than one user and one developer. See http://bugs.python.org/issue6939

As Benjamin noted, that change was discussed on python-dev and actually made at Guido's direction.

So, I think 1) the supposed bugfix-only policy should really be the policy; 2) the violation in 3.1.2 should be reverted in 3.1.3, and the API change reviewed in the normal 3.2 alpha/beta process. I am curious as to what others think on both points.

The bugfix-only policy remains in place, but there are corner cases (such as this one) where the definition of what is and isn't a bug gets fuzzy and we need to make a judgment call as to whether to fix them or not. In particular, fixing bugs often runs the risk of breaking existing workarounds for those bugs.

The decimal module, for example, has a standing policy to treat deviations from the standard as bugs, and this may lead to changes in the module if the standard is updated between two releases.

This specific change was discussed on python-dev and the chance of breaking existing 3.1 code was deemed preferable to retaining semantics that were seen as broken, so I would be against reverting it.

However, it may be worth modifying the policy to ensure that such exceptional bug fixes be mentioned prominently in the release notes and on the download page for that maintenance release.

Regards, Nick.

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

More information about the Python-Dev mailing list