[pycrypto] Suggestions for patches

Dwayne C. Litzenberger dlitz at dlitz.net
Mon Nov 29 22:01:58 CST 2010


Here are some ideas for PyCrypto patches:

- Documentation updates

- Bugfixes

- Python 3.x support, with some sane way of maintaining Python 2.x support 
   for the forseeable future.  I would like to see somebody champion this, 
   with discussion on how this could realistically work, rather than just 
   one-off code dumps.

- Build autoconfiguration improvements

- 64-bit Windows support

- Camellia.  Maybe.  I don't want lots of new algorithms, but having more 
   than one cipher with a 128-bit block size is probably a good idea, 
   assuming the code is clean and doesn't carry any substantial copyright 
   restrictions.

Here are some tips for getting your patches accepted, taken from 
http://www.pycrypto.org/:

- Don't needlessly break compatibility with older versions of PyCrypto. 
   Patches that break compatibility with older version of PyCrypto, 
   especially PyCrypto 2.0.1, will need an explanation about why it's worth 
   breaking compatibility. Exception: Removing buggy code that nobody uses 
   is fine.

- Don't needlessly break compatibility with older versions of Python. Run 
   the test suite using Python 2.1 and the latest version of Python 2.x.

- Don't needlessly add complexity. The more complex the code is, the harder 
   it is to maintain, and the more likely it is to have bugs.

- Don't needlessly add features. Seriously. X.509 doesn't belong in 
   PyCrypto. Or anywhere, really.

- Don't create copyright headaches. It took me the better part of a year to 
   sort out the licensing ambiguities in PyCrypto 2.0.1. If you're adding 
   new files, include the standard PyCrypto public domain dedication at the 
   top.

- Whatever you do in _fastmath.c, also do in _slowmath.py. PyCrypto has two 
   math libraries: one that depends on libgmp, and one that doesn't. They 
   need to be kept synchronized with each other.

- Make small, incremental, well-documented changes. Your commit messages 
   should be clear and detailed. Include any applicable background 
   information. Your patches should do one thing. Your code should have 
   sensible comments.

I still don't have a lot of time to actually write code, but I'm going to 
try to be more responsive to posts on the mailing list, especially if those 
posts can be read and responded to on my phone. :-)

Cheers,
- Dwayne

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


More information about the pycrypto mailing list