[Python-Dev] PEP 384 accepted (original) (raw)

"Martin v. Löwis" martin at v.loewis.de
Fri Dec 3 08:31:27 CET 2010

I wonder what your definition of “unmaintained” is.

In this specific case: doesn't get feature requests acted upon. I'm well aware that you are fixing bugs, and that is appreciated.

Sure, distutils is not as well-maintained as other modules, but a dozen bugs have been fixed by five or six of us since the revert. I do feel responsible for all 116 remaining bugs, and intend to address all of them.

But if the resolution of the bug would require a new feature, your answer will be "this is going to be fixed in distutils2 (if at all), it's out of scope for distutils". Before, if the submitter contributed a patch, the patch was just unreviewed for a long time, unless one of the committers picked it up. Now, the patch will be rejected, which I consider worse - because the patch is not being rejected on its own merits, but just because of a policy decision to not improve distutils anymore.

For example, I keep running into the issue that distutils doesn't currently support parallel builds. I have been pondering supporting "-j" for building extensions, using both unbounded "-j" and the GNU make style -jN build server. However, I know that the patch will be rejected, so I don't even start working on it.

On the matter of freeze exceptions, there have been two: - reading the makefile with surogateescape error handler so that python can build with an ASCII locale in a non-ASCII path (haypo, #6011) - handle soabiflags (barry, #9807). I took part in the discussion before those changes and did not object to them: they are very small changes that enable a new feature of Python 3.2. Maybe I should have requested Tarek’s approval for those changes; he knows better than me how third parties may break because of changes that don’t seem to break anything.

I see. Now, I'd claim that the reasoning as to why an abi= parameter on Extension may break things also applies to the soabiflags: to support soabiflags, the INSTALL_SCHEMES syntax was modified. If the install command is subclassed, that could lead to funny interactions, e.g. where the subclass fails to put abiflags into config_vars. IIUC, subst_vars will then eventually raise a ValueError.

I'm not saying that this is a likely scenario - only that the reasoning "if a change can possibly affect existing code, it should not be made" applies to essentially any change. So if you want to avoid breaking things with certainty, not even bug fixes would be acceptable.

Regards, Martin

More information about the Python-Dev mailing list