On "PEP 546 — Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7"
The reason we're having this conversation at all is probably a matter of timing. If MemoryBIO was in Python 3 when PEP 466 was accepted, it surely would have come along for the ride to 2.7. I believe PEP 466 is generally considered to have produced positive results. PEP 546, carrying no breaking changes, is less risky than PEP 466. The reluctance to bend 2.7 rules is healthy. This PEP is part of the price we pay, though, for making a backwards-incompatible release. The security landscape has and will change over the 10+ python-dev-supported life span of 2.7. During that time, we have an obligation to keep Python 2 secure. Part of that is supporting modern security interfaces, which are features. This change is needed to make another stdlib feature, ensurepip (which is itself yet another 2.7.x backport) work well. Therefore, as 2.7 release manager, I'm accepting the PEP.
Well reasoned! On Fri, Jun 9, 2017 at 4:56 PM, Benjamin Peterson <benjamin@python.org> wrote:
The reason we're having this conversation at all is probably a matter of timing. If MemoryBIO was in Python 3 when PEP 466 was accepted, it surely would have come along for the ride to 2.7. I believe PEP 466 is generally considered to have produced positive results. PEP 546, carrying no breaking changes, is less risky than PEP 466.
The reluctance to bend 2.7 rules is healthy. This PEP is part of the price we pay, though, for making a backwards-incompatible release. The security landscape has and will change over the 10+ python-dev-supported life span of 2.7. During that time, we have an obligation to keep Python 2 secure. Part of that is supporting modern security interfaces, which are features. This change is needed to make another stdlib feature, ensurepip (which is itself yet another 2.7.x backport) work well.
Therefore, as 2.7 release manager, I'm accepting the PEP.
_______________________________________________ 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/ guido%40python.org
-- --Guido van Rossum (python.org/~guido)
On Fri, Jun 9, 2017 at 4:56 PM, Benjamin Peterson <benjamin@python.org> wrote: Therefore, as 2.7 release manager, I'm accepting the PEP.
2017-06-10 3:03 GMT+02:00 Guido van Rossum <guido@python.org>:
Well reasoned!
Guido: by default, you are the only one who pronounces officially on a PEP. Should I understand that you approved the PEP? I would prefer a more explicit email, just to prevent confusion :-) Victor
On Sat, Jun 10, 2017 at 2:09 AM, Victor Stinner <victor.stinner@gmail.com> wrote:
On Fri, Jun 9, 2017 at 4:56 PM, Benjamin Peterson <benjamin@python.org> wrote: Therefore, as 2.7 release manager, I'm accepting the PEP.
2017-06-10 3:03 GMT+02:00 Guido van Rossum <guido@python.org>:
Well reasoned!
Guido: by default, you are the only one who pronounces officially on a PEP. Should I understand that you approved the PEP? I would prefer a more explicit email, just to prevent confusion :-)
Oh, sorry! Let's retroactively make Benjamin the BDFL-delegate for this PEP. The effect is the same: the PEP is officially accepted. You can update the PEP headers to reflect that. -- --Guido van Rossum (python.org/~guido)
Le 10 juin 2017 22:09, "Guido van Rossum" <guido@python.org> a écrit : Let's retroactively make Benjamin the BDFL-delegate for this PEP. The effect is the same: the PEP is officially accepted. Ok fine, I will update the PEP and then start to work on review the old implementation written by Alex Gaynor. Victor
On 2017-06-10 01:56, Benjamin Peterson wrote:
The reason we're having this conversation at all is probably a matter of timing. If MemoryBIO was in Python 3 when PEP 466 was accepted, it surely would have come along for the ride to 2.7. I believe PEP 466 is generally considered to have produced positive results. PEP 546, carrying no breaking changes, is less risky than PEP 466.
The reluctance to bend 2.7 rules is healthy. This PEP is part of the price we pay, though, for making a backwards-incompatible release. The security landscape has and will change over the 10+ python-dev-supported life span of 2.7. During that time, we have an obligation to keep Python 2 secure. Part of that is supporting modern security interfaces, which are features. This change is needed to make another stdlib feature, ensurepip (which is itself yet another 2.7.x backport) work well.
Therefore, as 2.7 release manager, I'm accepting the PEP.
That's fantastic news. Thanks Benjamin! Christian
On 10 June 2017 at 09:56, Benjamin Peterson <benjamin@python.org> wrote:
The reason we're having this conversation at all is probably a matter of timing. If MemoryBIO was in Python 3 when PEP 466 was accepted, it surely would have come along for the ride to 2.7. I believe PEP 466 is generally considered to have produced positive results. PEP 546, carrying no breaking changes, is less risky than PEP 466.
The reluctance to bend 2.7 rules is healthy. This PEP is part of the price we pay, though, for making a backwards-incompatible release. The security landscape has and will change over the 10+ python-dev-supported life span of 2.7. During that time, we have an obligation to keep Python 2 secure. Part of that is supporting modern security interfaces, which are features. This change is needed to make another stdlib feature, ensurepip (which is itself yet another 2.7.x backport) work well.
Therefore, as 2.7 release manager, I'm accepting the PEP.
Thanks Benjamin. I was just about to post in the other thread to say I thought this was the right way to go, as I think our experience with PEP 476 (the switch to validating HTTPS certificates by default) is illustrative here: we (Red Hat) technically *didn't* backport that PEP as originally written into RHEL (and hence into CentOS etc). Instead, we had folks primarily from Red Hat, eGenix, and Canonical figure out the variant covered in PEP 493 that eventually became the system Python behaviour in RHEL 7.3+. So even if we eventually decide we can't backport PEP 546 into the RHEL system Python as written: - it will still be in Ubuntu 18.04+ - it will still make its way into future versions of other long term support distributions (whether community driven or commercial) - it will still make its way into Red Hat Software Collections at some point - we're still free to write a follow-up PEP for an opt-in _ssl_backport bootstrapping module if/when there's a clearer benefit to justify the additional effort Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Agreed, that’s good reasoning. Thanks for short-circuiting the discussion! Cheers, Steve Top-posted from my Windows phone From: Benjamin Peterson Sent: Friday, June 9, 2017 16:59 To: python-dev@python.org Subject: [Python-Dev] On "PEP 546 — Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7" The reason we're having this conversation at all is probably a matter of timing. If MemoryBIO was in Python 3 when PEP 466 was accepted, it surely would have come along for the ride to 2.7. I believe PEP 466 is generally considered to have produced positive results. PEP 546, carrying no breaking changes, is less risky than PEP 466. The reluctance to bend 2.7 rules is healthy. This PEP is part of the price we pay, though, for making a backwards-incompatible release. The security landscape has and will change over the 10+ python-dev-supported life span of 2.7. During that time, we have an obligation to keep Python 2 secure. Part of that is supporting modern security interfaces, which are features. This change is needed to make another stdlib feature, ensurepip (which is itself yet another 2.7.x backport) work well. Therefore, as 2.7 release manager, I'm accepting the PEP.
Thank you Benjamin ;-) Victor Le 10 juin 2017 01:58, "Benjamin Peterson" <benjamin@python.org> a écrit :
The reason we're having this conversation at all is probably a matter of timing. If MemoryBIO was in Python 3 when PEP 466 was accepted, it surely would have come along for the ride to 2.7. I believe PEP 466 is generally considered to have produced positive results. PEP 546, carrying no breaking changes, is less risky than PEP 466.
The reluctance to bend 2.7 rules is healthy. This PEP is part of the price we pay, though, for making a backwards-incompatible release. The security landscape has and will change over the 10+ python-dev-supported life span of 2.7. During that time, we have an obligation to keep Python 2 secure. Part of that is supporting modern security interfaces, which are features. This change is needed to make another stdlib feature, ensurepip (which is itself yet another 2.7.x backport) work well.
Therefore, as 2.7 release manager, I'm accepting the PEP.
_______________________________________________ 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/ victor.stinner%40gmail.com
FYI I started to work on the implementation: I rebased Alex Gaynor's patch written in 2014 and converted it to a pull request. http://bugs.python.org/issue22559 Victor 2017-06-10 1:56 GMT+02:00 Benjamin Peterson <benjamin@python.org>:
The reason we're having this conversation at all is probably a matter of timing. If MemoryBIO was in Python 3 when PEP 466 was accepted, it surely would have come along for the ride to 2.7. I believe PEP 466 is generally considered to have produced positive results. PEP 546, carrying no breaking changes, is less risky than PEP 466.
The reluctance to bend 2.7 rules is healthy. This PEP is part of the price we pay, though, for making a backwards-incompatible release. The security landscape has and will change over the 10+ python-dev-supported life span of 2.7. During that time, we have an obligation to keep Python 2 secure. Part of that is supporting modern security interfaces, which are features. This change is needed to make another stdlib feature, ensurepip (which is itself yet another 2.7.x backport) work well.
Therefore, as 2.7 release manager, I'm accepting the PEP.
_______________________________________________ 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/victor.stinner%40gmail.co...
participants (6)
-
Benjamin Peterson -
Christian Heimes -
Guido van Rossum -
Nick Coghlan -
Steve Dower -
Victor Stinner