On Sat, Feb 1, 2014 at 2:00 PM, Vinay Sajip <vinay_sajip@yahoo.co.uk> wrote:

On Sat, 1/2/14, Brett Cannon <brett@python.org> wrote:

> Yes, that is definitely a design flaw in the ssl module that should
> get remedied. Did you file a bug to add a new API (whether new
> function or new parameters) to accept a file-like object or string
> instead?

While that might improve flexibility in how you use the ssl module, it
sadly won't solve the problem in general. Some third party APIs
will expect file paths, whereas others will require passing OS-level
handles, rather than file-like objects - thus effectively requiring a
file which you can open with os.open().

No one is talking about solving this problem overnight. But if we don't want to bother putting the effort in now then the zipimport module might as well get tossed as this is a constant issue that people are not designing APIs to support. So if people are going to implicitly not support it because no one is asking for them to care then we shouldn't try to support it ourselves and make our lives easier (gods know the zipimport module is a pain to keep working).

There are other Python APIs which need a pathname - I know
imp.load_dynamic() will be familiar to you :-)

Sure, but that's for technical reasons so it gets a pass (plus I didn't design that API =).