[Python-Dev] PEP 384 accepted

[Éric Araujo]

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 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.
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