[pycrypto] Py3k changes - rebase

[Dwayne C. Litzenberger]

Sure, that will do.

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

>Dwayne,
>
>
>> No, each commit should be a distinct change (and each distinct change
>> should have its own commit).  Having separate commits for the
>following
>> 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
>and
>>         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
>those, 
>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
>changes 
>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.
>
>Thorsten

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