[pycrypto] Py3k changes - rebase

Dwayne C. Litzenberger dlitz at dlitz.net
Sat Feb 19 19:02:32 CST 2011

Sure, that will do.

"Thorsten Behrens" <sbehrens at gmx.li> wrote:

>> No, each commit should be a distinct change (and each distinct change
>> should have its own commit).  Having separate commits for the
>> makes sense:
>>       - Replace tabs with spaces
>>       - Py3K _fastmath.c support
>>       - Change _fastmath.c to compile with VC++
>>       - add MPIR support
>>       - Add Ron Rivest Test
>>       - Add unit tests for Crypto.Random.random
>>       - Update documentation with current state of security of hash
>>         cipher functions.
>>       - Update documentation with Python 3.x notes.
>>       - Add unit test for AllOrNothing
>>       - Fix AllOrNothing and random.sample()
>I took a stab at just a portion of this, the first _fastmath.c changes.
>The result is that I have a lot of conflicts, and after resolving
>I have code that won't compile.
>I can't easily untangle these changes: The additional unit tests either
>presume that the py3k compatibility layer is there, or are needed to 
>make the library work under py3k.
>I have a limited amount of enthusiasm for fixing that which already 
>works, so it fits into a neater order. Here's my compromise proposal:
>I will change the unit tests to wrap the test vectors in a different 
>place, instead of wrapping the literals, as we had discussed.
>And I will give you a branch with one commit that has all of the
>that were made.
>I understand the desire for incremental commits. I can keep it in mind 
>in future, with the better understanding of git that I now have. For 
>this py3k change, though, the amount of work needed to attempt to 
>"unravel" the change and bring it in order is too great for me to want 
>to tackle it. The best I can offer is the compromise above.
>I could go on - I'll refrain. Hope to hear from you soon.

Sent from my Android phone with K-9 Mail. Please excuse my brevity.

More information about the pycrypto mailing list