[pycrypto] Need your input: Major modernization; dropping legacy Python support?
campadrenalin at gmail.com
Wed Oct 30 08:44:13 PDT 2013
I think you're going to get mostly anecdotal answers to this, fairly
personal to whoever is answering it, but here's what I consider important:
- Clean, modern, easy-to-use API (that limits your ability to
accidentally misuse stuff)
- Rapid development/developer-friendly codebase
- Nice documentation (willing to contribute to this personally)
- Elliptic curve cryptography (ECC)
- Ability to install via pip, even on machines that don't already have
Conversely, I don't care about the following (although some/many probably
- Backwards compatibility. As long as there's documentation, I'd rather
deal with the byproducts of progress than a crippled interface.
- Distro packaging.
- Internal details of how PyCrypto works, as long as it fulfills the
- Legacy Python versions (your definition matches mine).
- License, so long as I can use it from an LGPL package (which seems
compatible with Apache2)
Hopefully this feedback helps!
On Tue, Oct 29, 2013 at 11:58 PM, Dave Pawson <dave.pawson at gmail.com> wrote:
> On 30 October 2013 06:09, Dwayne Litzenberger <dlitz at dlitz.net> wrote:
> > 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.
> For some reason, Fedora is still pushing Python 2.7, so I'd be happy
> with this position.
> > 4. What if Crypto.* became a wrapper around some other crypto library?
> What logic please?
> > Of particular concern is FOSS distributors packaging PyCrypto (e.g.
> > distros, *BSD ports trees, MacPorts/HomeBrew, etc.), and anything else
> > might impact a large number of downstream end-users.
> Fedora seems a long way behind with the Python versions.
> > 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...
> I'll leave that to the more knowledgable.
> My position is I'm grateful for the code - meets my needs.
> Dave Pawson
> XSLT XSL-FO FAQ.
> Docbook FAQ.
> pycrypto mailing list
> pycrypto at lists.dlitz.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the pycrypto