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

[Lorenz Quack]

Hi,

On 30/10/13 06:09, Dwayne Litzenberger wrote:
 > Hi folks,
 >
 > I'm thinking about making some fairly drastic changes to PyCrypto (compared to what's happened historically) and I'd
 > like to know how these would impact people:

I'm only a very, very casual user but for what it's worth here come my 2 cents:

 >
> 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.

+1

>
> 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.
>

I like to keep dependencies as low as possible. Obviously, you always have to weigh the pros and cons. So I guess what I 
am saying is that is depends and should be decided on a case by case basis.

> 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.)
>

depends on what exactly you mean by "independent library". If you mean "maintained and shipped separately and added as a 
dependency" then I'm -1. There are enough crypto c-libs out there why add another one?
If you mean "have it in the pycrypto tree but compile it to a lib and use it via cffi just to make pypy happy" then I 
would like to see some performance analysis. The main reason to have stuff in C is performance if I am not mistaken. By 
hearsay I think that ctypes has quite a significant impact. what about cffi?

> 4. What if Crypto.* became a wrapper around some other crypto library?

I believe most crypto libs already have a python wrapper. How would pycrypto be differnet?

>
> 5. The Apache License 2.0.  What if PyCrypto were licensed under it, or    included dependencies that are licensed under
> it?
>

Why? What would that achieve/improve? What's wrong with the current state (more or less public domain)? Wouldn't you 
need to get the consent of every contributor?

> 6. What if src/*.c was mostly replaced with mostly just went away.
>

Wouldn't that totally kill performance? If the parts you want to kill are not security or performance sensitive: go for it!

That it.
Cheers and thanks for all your great work Dwayne!

//Lorenz


> Don't panic.  These aren't concrete plans yet, but I'd like to know how this might affect various downstream PyCrypto
> stakeholders, and problems I might expect to encounter if I went in any of these directions.
>
> Of particular concern is FOSS distributors packaging PyCrypto (e.g. Linux distros, *BSD ports trees, MacPorts/HomeBrew,
> etc.), and anything else that might impact a large number of downstream end-users.
>
> I've been maintaining backward compatibility in order to protect end-users from bugs introduced in downstream forks of
> PyCrypto, but that's made it hard to generate interest in working on PyCrypto.  From what I can tell, there are
> currently several Python crypto libraries, and none of them are particularly great (including PyCrypto).
>
> 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.  It might be better to merge PyCrypto with one or more other
> Python crypto libraries...
>
> Anyway, I'd love to hear what people have to say on this topic.
>