On 22 January 2014 22:15, Donald Stufft <don...@stufft.io> wrote: > > On Jan 22, 2014, at 6:58 AM, Nick Coghlan <ncogh...@gmail.com> wrote: >> >> The kinds of decisions that an application like a web browser or a >> package installer can make aren't necessarily available to a runtime. >> We had to be cautious even with the initial hash randomisation change >> to avoid breaking currently working applications. > > The same could be said for requests, it’s fundamentally not an application > and can’t control the interaction with the user and yet it validates TLS by > default just fine.
The requests library is used by a relatively small fraction of the Python community, and they're mostly web specialists that already understand the need for TLS-by-default and hence don't need it carefully explained to them. New users adopting it just treat that as the "way that requests works" and not something the language developers are forcing on them. >> Look at the anger that people express about us making Python 3 more >> sensitive to environment misconfiguration on POSIX systems: people >> don't blame the misconfigured environment that Python 2 tolerated with >> an increased risk of data corruption, they blame *us* for breaking >> something that used to work by default. > > They blame Python for breaking something that used to work by default > for something they feel has little or no benefit, and which is also difficult > or impossible to adapt to without often significant code changes (for > the people who I’ve seen blaming Python dev for). Which is exactly the way most non-web-specialists working inside the comfort of corporate and academic firewalls will react to a change that breaks their access to internal applications, where self-signed certs and improperly configured internal CAs are endemic (of course, that's assuming they're using HTTPS at all, which I admit is an optimistic assumption). >> There are currently still too many valid reasons for not using >> verified SSL for us to realistically make it the default without a >> seriously long transition period (not quite IPv6 or even Python 3 >> long, but certainly not as short as the time period involved in >> introducing hash randomisation). > > As I’ve said multiple times, I think it’s fine to send it through the > deprecation process which is still pretty long and gives people > a good chunk of time to update. Then I don't believe we actually have an argument here. Create the PEP with the rationale (written in terms a non-web-specialist can understand) and the deprecation strategy, and we can consider adding the initial deprecation warning in 3.5 next year. So, no rush on getting the PEP together :) 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
