On Fri, Jun 18, 2010 at 3:09 AM, Antoine Pitrou <report@bugs.python.org> wrote:
>
> Antoine Pitrou <pitrou@free.fr> added the comment:
>
> Le vendredi 18 juin 2010 à 06:46 +0000, geremy condra a écrit :
>> geremy condra <debatem1@gmail.com> added the comment:
>>
>> On Fri, Jun 18, 2010 at 2:39 AM, Daniel Urban <report@bugs.python.org> wrote:
>> >
>> > Daniel Urban <urban.dani+py@gmail.com> added the comment:
>> >
>> >>  * When I have thought about Python crypto in the stdlib, I've considered modeling it after hashlib, so you would get cipher = cryptolib.AES(bits=192, ...) etc. (Caveat: haven't thought it through.)
>> >
>> > I think there is a relevant PEP: PEP 272 -- API for Block Encryption Algorithms v1.0 (http://www.python.org/dev/peps/pep-0272/ )
>> > It describes an API somewhat similar to hashlib.
>>
>> Again, I'm not entirely opposed to this, but I think it represents a
>> lower-level API than most developers can really be safely trusted to
>> handle.
>
> If there is a contention or disagreement between different API styles,
> it may be wise to seek opinions on python-dev or python-ideas.

I'm not sure there's a disagreement here except what the top-level API
should be. If someone is really determined to use the lower-level API
I have no issue with it, and (within the bounds of time and ability)
am willing to write the code to support it.

> I'd point out that the "ssl" module itself seems to have evolved from a
> trivial wrapper API (in the 2.5 docs I can only find a single
> 3-parameter function, socket.ssl()) to a more comprehensive API in 3.2,
> because people ultimately need the functionalities.
> (and yet the ssl API in 3.2 is still much less featureful than M2Crypto
> or pyOpenSSL are)

I'm not sure I'm understanding what you mean. Are you saying it should
start as a comprehensive wrapper because that's what ssl is headed
towards or that it should start simply because such functionality will
evolve organically as the need arises?

Geremy Condra