Martin v. Loewis wrote:
"M.-A. Lemburg" firstname.lastname@example.org writes:
Patch level releases should *never* include new features (unless these are essential to fix a serious bug or a simple byproduct of a fix). I don't know where you got the impression that Python should move back to the 1.5 branch development process where patch levels added new features.
From discussions on python-dev...
Patch levels are there to stabilize a release, not make it more powerful.
What precisely does that mean?
Mainly that only bugs should be fixed. Adding new features doesn't help in fixing bugs since you can't expect that existing code for a particular Python branch will get changed to make use of it.
Stabilizing means that code using the existing features in a branch runs more stable, i.e. there are fewer situations where a program can trigger a bug hiding in the Python release.
Specific case in question: xml.dom.minidom.toxml does not support the specification of an encoding of the resulting XML document. Instead, if there are non-ASCII characters in the output document, it returns a Unicode object that starts with u"<?xml version='1.0' ?>". People cannot write this to a file as-is, and they cannot encode it in anything but UTF-8 (because the document would then be incorrect).
So I added an optional encoding= argument to .toxml, for 2.3. The question now is: should that argument also be made available for 2.2.2?
Adding the argument would only help applications which would make use of it. An application written for Python 2.2 couldn't do this since the optional argument wouldn't be available.
BTW, the above is trying to fix an application bug rather than a Python one: if the application cannot deal with Unicode, it is not non-ASCII compatible.