On 3/23/2014 8:03 PM, Barry Warsaw wrote:
On Mar 23, 2014, at 08:00 AM, Skip Montanaro wrote:
I'm unclear how this would be better than just biting the bullet and
making a 2.8 release. On the one hand, the 2.7.x number suggests
(based on the existing release protocol) that it should be a drop-in
replacement for earlier 2.7 micro releases. On the other hand, calling
it something like "ServerPython" implies that it's not necessary for
network client applications, when, if I read the PEP correctly, it
most certainly would be.
It seems to me that the problem the PEP addresses can largely be confined to
the Python 2.7 standard library and the fact that it's bundled with the
language. I want to stick to our no-Python-2.8 pledge, but I wonder if there
isn't a middle ground where we fork the stdlib into a separate branch, and
apply security specific changes there.
Python 2.7.x will always be the "standard stdlib". We would never release a
specific Python 2.7 + "security stdlib" release, but downstream developers
would be able to overlay this forked stdlib on top of the standard one.
Volunteers or corporate sponsors could distribute binary installers with this
combination of pure Python 2.7 language + "security enhanced stdlib", and
Linux distros could do the necessary building and distributing for their own
platforms if they so desired.
The trick is what do you call this new combination,
I have already agree that 'ServerPython' is just a placeholder.
> how do you invoke it, and how do you keep it distinct and
> independent of the system's standard Python 2.7?
Maybe this is some scent of Python 2.8 by another name, but let's never call
it Python 2.8.
I agree, no only because of the 'pledge', but because it is the wrong
model. Nick's latest paraphrase of where he thinks his proposal is
heading is "the SSL, hashlib and hmac modules are kept in sync with
Python 3 feature releases, but use the same default settings as the
original Python 2.7 release". '2.8' would imply a broader focus than
just 3 modules, and it would only work for the first of a series of
enhancement releases.
--
Terry Jan Reedy
_______________________________________________
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
