On Tue, Mar 25, 2014 at 7:12 PM, Cory Benfield <c...@lukasa.co.uk> wrote: > 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.
Exactly the same. If someone wants to distribute SEPython (that someone might be python.org itself, or ActiveState, or anyone else who has an interest in it), they're welcome to do so; and it could be done either as an all-in-one that packages all of CPython, or as an add-on; either way would work just as well, but the former would be cleaner. ChrisA _______________________________________________ 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
