Hi all,
I wanted to bring everyone up to speed on the status of PEP 466, what's been completed, and what's left to do.
First the completed stuff:
* hmac.compare_digest * hashlib.pbkdf2_hmac
Are both backported, and I've added support to use them in Django, so users should start seeing these benefits just as soon as we get a Python release into their hands.
Now the uncompleted stuff:
* Persistent file descriptor for ``os.urandom`` * SSL module
It's the SSL module that I'll spend the rest of this email talking about.
Backporting the features from the Python3 version of this module has proven more difficult than I had expected. This is primarily because the stdlib took a maintenance strategy that was different from what most Python projects have done for their 2/3 support: multiple independent codebases.
I've tried a few different strategies for the backport, none of which has worked:
* Copying the ``ssl.py``, ``test_ssl.py``, and ``_ssl.c`` files from Python3 and trying to port all the code. * Coping just ``test_ssl.py`` and then copying individual chunks/functions as necessary to get stuff to pass. * Manually doing stuff.
All of these proved to be a massive undertaking, and made it too easy to accidentally introduce breaking changes.
I've come up with a new approach, which I believe is most likely to be successful, but I'll need help to implement it.
The idea is to find the most recent commit which is a parent of both the ``2.7`` and ``default`` branches. Then take every single change to an ``ssl`` related file on the ``default`` branch, and attempt to replay it on the ``2.7`` branch. Require manual review on each commit to make sure it compiles, and to ensure it doesn't make any backwards incompatible changes.
I think this provides the most iterative and guided approach to getting this done.
I can do all the work of reviewing each commit, but I need some help from a mercurial expert to automate the cherry-picking/rebasing of every single commit.
What do folks think? Does this approach make sense? Anyone willing to help with the mercurial scripting?
Cheers, Alex
On 1 Jul 2014 11:28, "Alex Gaynor" alex.gaynor@gmail.com wrote:
I've come up with a new approach, which I believe is most likely to be successful, but I'll need help to implement it.
The idea is to find the most recent commit which is a parent of both the ``2.7`` and ``default`` branches. Then take every single change to an
``ssl``
related file on the ``default`` branch, and attempt to replay it on the
``2.7``
branch. Require manual review on each commit to make sure it compiles,
and to
ensure it doesn't make any backwards incompatible changes.
I think this provides the most iterative and guided approach to getting
this
done.
Sounds promising, although it may still have some challenges if the SSL code depends on earlier changes to other code.
I can do all the work of reviewing each commit, but I need some help from
a
mercurial expert to automate the cherry-picking/rebasing of every single commit.
What do folks think? Does this approach make sense? Anyone willing to
help with
the mercurial scripting?
For the Mercurial part, it's probably worth posing that as a Stack Overflow question:
Given two named branches in http://hg.python.org (default and 2.7) and 4 files (Python module, C module, tests, docs): - find the common ancestor - find all the commits affecting those files on default & graft them to 2.7 (with a chance to test and edit each one first)
It's just a better environment for asking & answering that kind of question :)
Cheers, Nick.
Cheers, Alex
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/ncoghlan%40gmail.com
Le 01/07/2014 14:26, Alex Gaynor a écrit :
I can do all the work of reviewing each commit, but I need some help from a mercurial expert to automate the cherry-picking/rebasing of every single commit.
What do folks think? Does this approach make sense? Anyone willing to help with the mercurial scripting?
I don't think this makes much sense; Mercurial won't be smarter than you are. I think you'd have a better chance of succeeding by backporting one feature at a time. IMO, you'd first want to backport the _SSLContext base class and SSLContext.wrap_socket(). The latter *will* require some manual coding to adapt to 2.7's different SSLSocket implementation, not just applying patch hunks around.
Regards
Antoine.
I have to agree with Antoine -- I don't think there's a shortcut that avoids *someone* actually having to understand the code to the point of being able to recreate the same behavior in the different context (pun not intended) of Python 2.
On Tue, Jul 1, 2014 at 1:54 PM, Antoine Pitrou antoine@python.org wrote:
Le 01/07/2014 14:26, Alex Gaynor a écrit :
I can do all the work of reviewing each commit, but I need some help from a mercurial expert to automate the cherry-picking/rebasing of every single commit.
What do folks think? Does this approach make sense? Anyone willing to help with the mercurial scripting?
I don't think this makes much sense; Mercurial won't be smarter than you are. I think you'd have a better chance of succeeding by backporting one feature at a time. IMO, you'd first want to backport the _SSLContext base class and SSLContext.wrap_socket(). The latter *will* require some manual coding to adapt to 2.7's different SSLSocket implementation, not just applying patch hunks around.
Regards
Antoine.
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
-
Alex Gaynor -
Antoine Pitrou -
Guido van Rossum -
Nick Coghlan