> I think it is kind of OK to require explicit specification of the
> ca_certs as long as it is made clear in all the relevant places that
> it _has_ to be done. I think it would be a good idea to deprecate the
> default value for ca_certs and issue a warning if ca_certs hasn't been
> specified (as None or a path).

The recommended way from Python 3.2 upwards is to define a SSLContext
and use it when doing SSL operations. Many APIs have been updated to
accept a context, a few are remaining as I've said in my first comment.

> I have heard that some Python variants come with the system ca_certs
> built in and hard-coded somehow.

This is really "some OpenSSL variants" rather than "some Python
variants". We can't control how the system (or user-supplied) OpenSSL is
built.
This "feature" is exposed in SSLContext.set_default_verify_paths() (see
http://docs.python.org/dev/library/ssl.html#ssl.SSLContext.set_default_verify_paths),
with the caveat that you don't know whether it succeeded at all.

> That is in a way very nice and convenient and a good solution (as long
> the user wants to use the same ca_certs for all purposes), but it
> would have to be available and reliable on all platforms to be really
> useful.

Well, for one, it probably won't be effective on Windows builds, since
it's really not Python's job to define a set of reliable CA certificates
(unless Martin wants to take that responsibility, that is), and Windows
doesn't have a set of system certificates in the PEM format AFAIK.