This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author lemburg
Recipients alex, barry, bkabrda, doko, dstufft, janssen, lemburg, ncoghlan, pitrou, r.david.murray, rkuska, vstinner
Date 2015-04-05.20:06:26
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <552195C0.3050207@egenix.com>
In-reply-to <1428263324.51.0.759551760573.issue23857@psf.upfronthosting.co.za>
Content
On 05.04.2015 21:48, Donald Stufft wrote:
> 
> Donald Stufft added the comment:
> 
>> No, I want to be able to easily disable the newly added
>> checks in 2.7.9+ to get systems such as these behave the
>> same as with 2.7.8, since without this option, people
>> using these system are going to be forced to stick with
>> buggy 2.7.8 systems.
> 
> Why is the monkeypatch in sitecustomize.py unacceptable? I understand why it's
> unacceptable to Nick and rkuska, they are a vendor and they don't want to write
> sitecustomize.py when the machine operator may want to use that file, however
> you're the machine operator in this case.

I don't consider monkey patching a proper way to configure a Python
installation.

I could simply patch the Python installation directly, but this is just
me. I'm talking about sys admins out there who don't know enough about
Python to be able to patch Python or write a sitecutomize.py which
uses monkey patching to fix the issue.

I also cannot recommend to our customers to monkey patch
Python just to get it running again. This is not what folks
expect from a production quality system :-)
History
Date User Action Args
2015-04-05 20:06:26lemburgsetrecipients: + lemburg, barry, doko, ncoghlan, janssen, pitrou, vstinner, alex, r.david.murray, bkabrda, dstufft, rkuska
2015-04-05 20:06:26lemburglinkissue23857 messages
2015-04-05 20:06:26lemburgcreate