[pycrypto] Once again: Python3 with PyCrypto

[Thorsten Behrens]

Johannes, Dwayne,

now that pycrypto accepts US contributions, I'm happy to at least give Python 3.x support some thought and investigation. So as to not re-invent the wheel: Johannes, what's the status of your efforts to date?

>>
I don't really know what's  involved in doing Py3k support, but I'd like to see it happen, provided
that it doesn't involve breaking Python 2.x support or a lot of unnecessary code duplication.
>>

Agreed. It's a matter of staying away from 3.x-only features (a pretty good list can be found here: http://sayspy.blogspot.com/2010/08/what-will-forever-be-exclusive-to.html), and I'd say even features that have been backported into 2.6 and 2.7. That is, focus on rewriting things that will break 3.x in such a way that they stay supported in 2.x. I'll caution that I haven't been through that exercise. I imagine it should be non-trivial but also not a huge pain for pycrypto, but I'm not willing to wager on that hunch.

The biggest hurdle has already been overcome: You'd like to see it happen. That's not a given in the Python community right now, I am made to understand. :)

>>
How do other Python projects that have C code maintain  compatibility across both Python 2.x and 3.x?
>>

There are some guidelines at http://docs.python.org/release/3.0.1/howto/cporting.html#cporting-howto. Looks like the int/long unification can be handled pretty well, by using aliases. str/unicode may be an issue, since 2.6 has a compatibility header, but earlier versions don't. Depends on how much those functions are in use in the pycrypto C modules. And then there's module unit/status, which looks like a pain, though do-able.

Yours
Thorsten