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 | ncogh...@gmail.com | Brisbane, Australia --------------------------------------------------------------- _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
