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

Éric Araujo merwok at netwok.org
Fri Dec 3 13:27:23 CET 2010

Le 03/12/2010 08:31, Martin v. Löwis a écrit :

I wonder what your definition of “unmaintained” is. In this specific case: doesn't get feature requests acted upon. Thanks for clarifying. I think that’s a stretch, but I see your meaning now.

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. The patch would not be rejected, but assigned to a different version. It‘s not different than replying to an old bug with a patch for Python 2.5 and requesting that it be updated for py3k. It’s also not uncommon to have another contributor or a core dev updating the patch if the original poster does not reply.

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. This would be a very useful feature for distutils2.

On the matter of freeze exceptions, there have been two: [snip] 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 INSTALLSCHEMES 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 configvars. IIUC, substvars will then eventually raise a ValueError. This is a concern.

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. If we wanted 100% certainty, yes.

Regards

More information about the Python-Dev mailing list