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

The former. Evolving organically has quite a few issues, because the
original API may be far from ideal to build on, and yet you have to
ensure compatibility with that API.
("comprehensive" doesn't have to equate "exhaustive" of course. But any
API which tries to simplify things too much might also be a roadblock
when it comes to exposing more features)