[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted

Luke Kenneth Casson Leighton report at bugs.python.org
Sat Nov 13 00:39:22 CET 2010

Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

erik, i'm really sorry, but the freeze on distutils simply cannot be accepted: there really is no other way, as you can see from the previous walkthrough analysis, and is reinforced by the further analysis below.

simply put: if the freeze on distutils is not lifted, then this entire set of work, which has been going on for years and _precedes_ the distutils freeze by at least 18 months, is completely, utterly and totally wasted.

let's walk through the situation where distutils2 is forced to be used.

what you're asking for is, basically, that every single third party package, of which there must be tens of thousands, must be patched for compilation on mingw32... _just_ so that it says "if sys.platform == 'mingw32': from distutils2.core import setup else: from distutils.core import setup", is that correct?

does that strike you as being completely and utterly unreasonable an expectation, to ask third parties to modify setup.py scripts which have worked perfectly well for years, many of which are likely to no longer even have a maintainer?

that leaves patching - which should be nothing more than _adding_ to - not "changing existing compilers" - ADDING an extra compiler - distutils as the only option.

now, that can be done monkey-patch style (i.e. at runtime, by adding in code very early on in python startup, or perhaps by patching the import system to replace the word "distutils" with "distutilsmingw32") or it can be done... by lifting the distutils freeze.

perhaps i should ask: what _exactly_ is the problem, and why do several teams complete and utter failure to do the correct thing by making changes to _existing_ compile platforms have anything to do with _this_ team's patches which add a new totally separate platform that has absolutely nothing to do with any of the other platforms?

i could say more, but i believe the point is clear: none of the people involved in seeing mingw32 added as a platform had _anything_ to do with the past failures, so why "punish" and mis-trust the python-mingw32 for other peoples' failures?

nosy: +lkcl

Python tracker <report at bugs.python.org>

More information about the Python-bugs-list mailing list