On 22 March 2014 21:11, Nick Coghlan <ncogh...@gmail.com> wrote:
> Full PEP included inline below, and available in more readable form at
> http://www.python.org/dev/peps/pep-0466/
Disclaimer: I pretty much don't use 2.x, or write server-type
software, so my practical requirement for the changes proposed here is
negligible.
Having thought about the points in the discussion so far, it seems to me:
1. The only real issue is 2.7, so the PEP should limit itself to "how
do we deal with 2.7".
2. The PEP talks vaguely about commercial support for the security
changes. I'm not quite sure what's being said here - I suspect Nick
has some concrete input from Red Hat here, but he's trying to keep
from being too specific in the PEP. I don't think that's necessarily
helpful. If the proposal is "Companies who want backported security
features can provide patches and this is how python-dev will evaluate
them" then let's say that. At the moment, there's a feel in the PEP
that python-dev are proposing to do the backports, and I'm not sure
that's true. As written, the PEP risks exposing python-dev to
accusations of not having delivered the improved security that the PEP
promises.
3. If companies want specific security enhancements, there's nothing
to stop them developing a patch, writing a PEP and proposing it to
python-dev. The first such patch would trigger pretty much the current
debate (is it OK to add an enhancement to 2.7, because it is for
security reasons?) but with the benefit of being about something
specific. Further proposals along the same lines could reference the
first PEP as justification for allowing subsequent security
enhancements.
4. A process like that described in (3) could happen right now. Why
isn't it? Presumably the need for such enhancements is there (or
there'd be no need for this PEP) so is it simply that companies like
Red Hat don't know that they have this option? Would it be better
simply to publish something explaining "How commercial vendors can
work with python-dev to deliver long-term support of Python 2.7".?
5. If the driver for this is Linux vendor support for 2.7, who is
going to provide the Windows/OSX/Solaris/etc implementations of new
features? Is "nobody" (implying that new features could end up being
Linux-only) an acceptable answer? Will the burden of adding
cross-platform support be on python-dev? Will patches be rejected
unless they cover all supported platforms (and will this be an
unacceptable burden for companies like Red Hat to take on)?
The situation with Python 2.7 has been understood for many years now.
Individual end users may not have thought through the implications and
we have a responsibility to support them. But companies like Red
Hat[1] are fully aware of their own release cycles, and the position
with Python 2.x is public knowledge. They have to take some share of
the blame for not planning for this situation (and they have paying
customers who expect them to handle this, unlike python-dev).
One problem here is that it's not at all clear what counts as "dealing
with a commercial vendor" means in the context of enhancements
(security or otherwise) to Python. We already have a route that's open
to anyone, so what else is needed? And why?
Most of the above is directed at the "commercial vendors can help out"
aspect of the PEP. With regard to the wider suggestion that security
enhancements be allowed for 2.7, we've been debating similar questions
in various forms for *ages*. There's been talk of a 2.8 release. There
have been ongoing discussions about helping people move to Python 3.
There have been many discussions about whether it's OK for
applications to remain on Python 2.7 (all of which said "yes, it's
fine" - maybe the security fix aspect makes that statement a little
less clear-cut). The fact that we haven't felt the need thus far to
change policy on 2.7 says that ("commercial vendors need it" aspects
aside) this is just another cycle of that same debate.
Paul
[1] I seem to be picking on Red Hat here. I'm not - it's just that the
RHEL support cycle is the most-often quoted example of commercial
support for Python 2.x, so I'm using that as my example.
_______________________________________________
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
