3.2 introduces SSL contexts, which allow bundling SSL configuration options, certificates and private keys into a single (potentially long-lived) structure.
http://docs.python.org/dev/py3k/library/ssl.html#ssl.SSLContext

The FTP_TLS constructor should allow passing an SSL context object instead of a key/cert pair.

I'm assigning this one to me.
Btw, before writing anything I think it would be better to decide what to do first, possibly by adopting the same approach everywhere (smtplib, imaplib, poplib, urllib and http.client).

My proposal:

• the user should still be able to use keyfile and certfile if desired, they're quicker to use and backward compatibility must be maintained.

• SSL context can be provided by passing a new "context" argument to the constructor.

• if context arg is passed FTP_TLS.ssl_version should be ignored and SSLContext.protocol used instead

• keyfile/certfile and context arguments should be mutually exclusive (ValueError)

Makes sense?

My proposal:

• the user should still be able to use keyfile and certfile if desired, they're quicker to use and backward compatibility must be maintained.

• SSL context can be provided by passing a new "context" argument to the constructor.

• if context arg is passed FTP_TLS.ssl_version should be ignored and SSLContext.protocol used instead

• keyfile/certfile and context arguments should be mutually exclusive (ValueError)

Makes sense?

Entirely sense to me :)

Patch in attachment.

Patch in attachment.

You could add checks for:

    self.assertIs(self.client.sock.context, ctx)
[...]
    self.assertIs(sock.context, ctx)

(I know, the "context" attribute isn't documented, I'm going to fix
this)

(I know, the "context" attribute isn't documented, I'm going to fix
this)

Now documented at:
http://docs.python.org/dev/py3k/library/ssl.html#ssl.SSLSocket.context

If you're fine with the current patch I can go on and commit it (including the context attribute test).

Committed in r81548.