[pycrypto] Need your input: Major modernization; dropping legacy Python support?

[Legrandin]

> 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
is self-contained.

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.