Python 3 support

[ben]

It'd be nice if pycryptopp supported Python 3 as more projects start gaining support for it.

[zooko]

Well, since a real user has formally requested it, I guess I'll go ahead and actually start paying attention to Python 3 now! I guess the first step is to turn on the feature of "warn me about stuff that I do which will break in Python 3". What's that flag called, -3?

[Nikratio]

Oh, if you're waiting for requests: I'm eagerly waiting for a Python 3 version too!

[zooko]

Okay, duly noted. I intend to support Python 3 in the future. The question of "when" however, is obviously strongly influenced by other people pitching in and doing some of the work, as I have a zillion other things to do and I don't personally expect to use Python 3 for the forseeable future.

So: yes, I approve in principle, will support people who contribute patches to make it happen, and will even probably write such patches myself someday.

Thanks for the feature request!

[Nikratio]

Just bumping this up again to assert that I haven't lost interest in this since my last request.

[zooko]

Hey, thanks for the encouragement! I'm really busy right now with a new startup and with Tahoe-LAFS v1.9. If anybody out there reading this wants to contribute some code, write patches to make pycryptopp source code work in both Python 2 and Python 3. For the parts of pycryptopp that are actually written in Python, you can use this library:

​http://packages.python.org/six/

However, most of the pycryptopp is written in C++ in the CPython API. I don't know how much that API changed from Python 2 to Python 3. I seem to recall that the Python developers deliberately tried to minimize unnecessary changes in that API, so hopefully it won't require a lot of porting.

[Nikratio]

Wouldn't it be easier to just run the Python parts through 2to3.py at install time? distutils/distribute can do that automatically. That's what I do for my Python modules.

[zooko]

I haven't tried it, so I don't know if it would be easier. My instinct is to stay far away from source-to-source translators. However, since I'm not currently volunteering to do the work, I would consider accepting and maintaining a patch from someone who did it that way. We would need strong automated testing so that if a new patch committed to the (Python 2) trunk causes a breakage in the Python 3 autogenerated version, we find out right away (by the unit tests detecting it and by the buildbot running those unit tests on every commit).

The amount of Python code in pycryptopp is so small that porting it to use the ​six library is probably little effort.

[zooko]

Coincidentally Benjamin Peterson, the maintainer of six and of 2to3, showed up on the #tahoe-lafs IRC channel tonight looking for secure distributed backup. I pointed this ticket out to him, and he said:

<gutworth> I also maintain 2to3, but I also have to agree, keeping one source is usually easier.

[zooko]

Here are some notes from Barry Warsaw about how he ported a CPython API module to be Python 3 and also still Python 3 compatible:

​http://mail.python.org/pipermail/python-porting/2011-November/000247.html

[zooko]

The next step on this is setting up Python 3 on buildslaves, or adding new buildslaves that run Python 3. You can help, by volunteering to operate a Python 3 buildslave.

[bsder]

Would like to ping this again. I'm getting some fairly obvious build failures on Python 3. Thanks.