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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
