[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