On 24 March 2014 19:37, Chris Angelico <ros...@gmail.com> wrote: > The opting in could be done at the distro level. Red Hat could ship a > thing called /usr/bin/python that runs SEPython, and that package > could be identified and numbered in such a way that it's clearly a > drop-in replacement for vanilla Python. If backward compatibility is > done carefully (which, from everything I'm seeing here, is the way > it's to be done), there should be absolutely no downside to using > SEPython, except for portability (because now you're depending on it > for security), and corner cases like testing.
What's your solution for OS X, Windows et al? My concern is that if you have a release called 'Python' and a release called 'Python with security stuff', a surprisingly large number of people will download the first, especially if the notes for the security release say 'this may cause some minor compatibility problems'. IMHO, I'd rather have good security be the default for everyone, and require an explicit opt-out to get the bad security release. _______________________________________________ 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
