[pycrypto] Once again: Python3 with PyCrypto

[Dwayne C. Litzenberger]

On Thu, Dec 23, 2010 at 08:20:28PM -0500, Thorsten Behrens wrote:
>Dwayne,
>
>I've looked into this some more. There are two basic approaches:
>
>a) Create .py code that will work in Python 2.x and 3.x. Code will 
>become uglier; for example try except blocks have to be used for 
>imports. One can catch a glimpse here: 
>http://pydev.blogspot.com/2008/11/making-code-work-in-python-2-and-3.html
>
>b) Leave .py code to be written for Python 2.x, with some cleanup 
>applied to redo constructs that cannot be converted by 2to3. When ready 
>to release, run 2to3 on the source tree, and release two versions: One 
>for Python 2.x, one for Python 3.x.
>
>b) is how the authors of Python intend things to be, and is likely the 
>cleanest way of operation. I don't relish the idea of following a) and 
>butchering the 2.x code so it will run in both 2.x and 3.x without change.
>
>The C code will require some #defines and some #ifdefs in places, to 
>deal with int/long, the fact that bytes are a type now and shouldn't be 
>strings (can be done with defines), and the module initialization code.
>
>Are you comfortable with b)? Objections? Reservations?

That sounds good to me, as long as it's not error-prone.  I don't have a 
problem with limiting myself to certain constructs, since I've been doing 
that for Python 2.1 support anyway.

>If you are good to give it a go, I'd need to know from you how you like 
>to handle branches in git. I'd assume that this work should be carried 
>out in a separate branch, not the trunk. This is going to touch a lot of 
>files.

Yes, it'll be in a separate branch for now.  As for the specifics, I don't   
know.  Try something and we'll see how it goes.  At some point, I might 
want to refactor it, but we'll deal with that when we have something more 
concrete.

-- 
Dwayne C. Litzenberger <dlitz at dlitz.net>
  OpenPGP: 19E1 1FE8 B3CF F273 ED17  4A24 928C EC13 39C2 5CF7