On 12 May 2015 at 20:56, M.-A. Lemburg <m...@egenix.com> wrote: > On 12.05.2015 12:04, Donald Stufft wrote: >> >>> On May 12, 2015, at 3:57 AM, M.-A. Lemburg <m...@egenix.com> wrote: >>> >>> In a user based installation (which most applications shipping >>> their own Python installation are), you can always do this >>> provided you can gain the application user permissions. >> >> Of course, if the application is shipping it’s own Python then >> it has to actually do something to update to 2.7.9 and it can >> add it’s own option to disable TLS verification. I personally >> think that the application providing that option is the *right* way >> and all these other things are, at best, just temporary shims until >> the applications do that. > > I still believe that requiring to monkeypatch Python is a very poor > approach in terms of quality software design. We can do better and > we should.
It's a deliberate design choice to actively discourage people from doing it - your "Ewww" reaction to monkeypatching is exactly the one we want. There's no technical reason for people to be bothered by it, since it's a documented and supported technique covered by the relevant PEP - it just so happens that the configuration being done is to switch a function alias between two different functions. Both of the recommended options I'm putting in the PEP (essentially the Red Hat design and the eGenix design, since we cover two different use cases) still adopt that same basic implementation model, they just provide ways for redistributors to move the configuration inside the SSL module itself if they decide it is in their users' interests for them to do so. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
