[PYTHON-CRYPTO] PEP 272 version 2

Andrew Kuchling akuchlin at mems-exchange.org
Thu Apr 18 17:29:47 CEST 2002


On Thu, Apr 18, 2002 at 03:41:04PM +0100, Phil Mayers wrote:
>TLS (I could do this in native python with the code I have), Kerberos
>(this is one I'm actually doing, in native Python), SPKM (ditto). It's

I was thinking of PGP/GPG, and perhaps if you wanted to write tools to
work with IPSEC packets (say, a smart tcpdump type of thing).

>I think the point is more - you *are* going to have block ciphers in
>Python. Why *not* have a standard API for them? Failing to do so means
>implementors can do what they like. This is inconsistent, difficult to
>learn, inelegant and wasteful.

Note, however, that this PEP is of type 'informational', and an
informational PEP carries as much weight as an informational RFC; that
is, none whatsoever.  Implementors *can* do what they like, and are
free to ignore the PEP if they don't like it or if it's unsuitable for
their application.  (At least that's what I've always thought
'informational' meant, though PEP 1 doesn't actually make that
explicit.  I'll talk to Barry Warsaw about clarifying this.)  For
example, the other informational PEPs are the Database API
specifications, and there are database modules that don't follow them.

--amk                                                             (www.amk.ca)
<looks at his palm> "I know this TARDIS like the back of my hand." <Leela turns
the Doctor's hand over>
    -- The Doctor, in "The Invasion of Time"





More information about the python-crypto mailing list