[pycrypto] Need your input: Major modernization; dropping legacy Python support?
helderijs at gmail.com
Wed Oct 30 14:43:08 PDT 2013
> 1. How many of you would really care if PyCrypto 2.6 was that last
> version to support legacy versions of Python? By "legacy", I mean all
> versions of Python that are NOT one of these:
> - Python 2.6.x
> - Python 2.7.x
> - Python 3.3 and above.
> I'd continue to make bugfix releases of PyCrypto 2.6.x, but add no
> more substantial new features.
That would be the wisest decision.
It is fair to say that there are a lot of production servers and
embedded platforms out there that are stuck to something as old as
Python 2.4, but they are hardly target for new developments. A
bugfixed PyCrypto 2.6.x is probably good enough for them.
> 2. I'm thinking of pulling in additional dependencies (e.g. cffi),
> requiring setuptools, and basically joining what the rest of the Python
> community is doing in 2013.
cffi is awesome. Is it friendly to cross-compile environments though?
That's rather important (to me at least).
For the same reason, I would be happy if autoconf was removed.
> 3. What if src/*.c were removed, and any relevant C code moved into an
> independent library, which could be loaded using cffi? (This is
> basically what we need to do to support PyPy properly.)
If by "independent" you mean a library not packaged with pycrypto,
then it would be bad. One of the strong points of pycrypto is that it
If you mean that C code is compiled into a library which is not a
python module as today, then it does not make any difference unless
the build becomes more complicated.
> 4. What if Crypto.* became a wrapper around some other crypto library?
I would probably stop using pycrypto. There are already M2Crypto,
pycryptopp and a bunch of others. They are good enough and battle
tested. There is no need for another one.
> 5. The Apache License 2.0. What if PyCrypto were licensed under it, or
> included dependencies that are licensed under it?
To me, it wouldn't make much difference.
> 6. What if src/*.c was mostly replaced with mostly just went away.
I don't understand this statement.
> I'm beginning to wonder how the risk of downstream forks compares to the
> risks that users face when developers still don't have a highly-visible,
> easy-to-use Python crypto API.
The pycryto API is already easy to use actually and it has the right
level of abstraction (=medium/low).
The main criticism one can move is that there are several booby traps
that a first-time user will surely trip on.
> It might be better to merge PyCrypto with
> one or more other Python crypto libraries...
"Merge with" as in "become a facade for" ?
I would stop using pycrypto too and just use to the other library.
More information about the pycrypto