[Python-Dev] PEP 384 accepted

["Martin v. Löwis"]

> 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