Hi there.
Thanks for your comments.  This is the kind of discussion I was hoping to have about my draft patch.

I too have reservations about adding arguments.  In the version of this that we have in house, we actually don't use a "certdata" argument, but rather this:
 - 'certfile' can be either a filename or a string containing the data.  The start of the string is examined to determine if is the latter

The reason I didn't do it this way in the patch is because:
a) it could be confusing and possibly un-pythonic to have that level of polymorphism employed
b) There are possible edge cases.  What if you had a filename that started with the magic tokens (unlikely but technically possible).

I also would prefer passing in the certificates as raw bytes data, rather than file-like objects.  there is no reason for them to be files, this is not data that is read on demand.  libssl reads the entire contents of these files in one gulp, so there is no efficiency to be gained through any sort of pipelining by providing a file-like-object..  Adding the plumbing inside the library to do python "read()" calls is completely unnecessary when the caller can simply do that.

The only possible reason would be to resolve the above ambiguity, i.e. to allow the api to try to invoke a "read()" function on the 'file' to determine if it is a file-like object.