```
import copy
import ssl

copy.copy(ssl.create_default_context())
```
results in 

`TypeError: can't pickle SSLContext objects`

This prevents me from being able to `copy.deepcopy()` an object that references `ssl.SSLContext`.

The apparent root cause is apparently that `ssl.SSLContext` passes an extra arg to its `__new__` method, but doesn't implement the method `__getnewargs__` that would let `copy` extract the extra arg.

This is rather a feature than a bug. It is not possible to make a copy of a SSLContext object because OpenSSL doesn't support the operation. A context contains elements that can't be cloned easily, e.g. session resumption tickets.

Hi Christian, thank you for following up. Here is my use case, and perhaps you can suggest something else that will work:

I am refactoring the transport layer in the Pika AMQP client library. The user provides an ssl.SSLContext instance for connecting to an AMQP broker (e.g., RabbitMQ). Pika will resolve the hostname via getaddrinfo and make attempts to establish TCP and AMQP connection to the candidate IP addresses until one succeeds in establishing an AMQP connection over SSL. Each connection attempt will require a fresh unadulterated clone of the ssl.SSLContext instance provided by user to avoid any side-effects from prior connection attempts.

How can I obtain this pristine clone cleanly for each new connection attempt?

Also, updating ssl.SSLContext documentation about intentional inability to copy generically and suggestion how to go about it if you need to obtain a clone or similar would be terrific and save developers time so they won't run into this gotcha when designing and implementing solutions. Many thanks!

> Each connection attempt will require a fresh unadulterated clone of the ssl.SSLContext instance provided by user to avoid any side-effects from prior connection attempts.

What would those side-effects be?

> What would those side-effects be?

Christian Heimes suggested that 
> A context contains elements that can't be cloned easily, e.g. session resumption tickets.

My concern then would be potential side-effects from such session resumption tickets and anything else that one connection attempt might save/change within an SSL Context that might have an undesirable side-effect on the follow-on connection attempts.

You won't have any session resumption tickets until a connection succeeds.  And even then, I don't think it would be a problem.  By design, SSL contexts are meant to be re-used accross multiple connections.

Antoine is correct. Session resumption is fully transparent for the application layer. The context object is designed to be reused by multiple connections to same or different servers.

PR 6099 changes error message "can't pickle SSLContext objects" to "cannot serialize SSLContext object", right? Wouldn't be better to change the standard error message instead?

It would be very helpful to make a statement in SSLContext's documentation to the effect that it's not copyable. This is frankly the first time I run into a non-copyable object.I spend quite a bit of time researching this after implementing a copying strategy that failed. It would have saved me (and others...) so much time is there was a warning in SSLContext documentation about not being able to serialize/copy/deepcopy by design!

Also, making that exception message more generic (ha, I wasn't pickling anything?!) as Serhiy Storchaka suggested would be a welcome addition, but not replacement for documentation.

Serhiy,
I don't understand what you are trying to tell me. "cannot serialize '%s' object" is used all over the interpreter, e.g. io, pickle, etree, and more. I feel it's the standard message.

Vitaly,
A lot of objects can't be copied. It's the general case for all kinds of objects that hold operating system resources (files, sockets) or wrap external C libraries (bz2, lzma, sqlite, ssl). We generally don't document that an object cannot be pickled, serialized, or copied. If documentation doesn't state that an object is copy-able or doesn't provide a dedicated copy method, than it can't be copied.

Thank you, I'll consider myself having been warned :)

On Sat, Mar 24, 2018, 7:28 AM Christian Heimes <report@bugs.python.org>
wrote:

>
> Christian Heimes <lists@cheimes.de> added the comment:
>
> Serhiy,
> I don't understand what you are trying to tell me. "cannot serialize '%s'
> object" is used all over the interpreter, e.g. io, pickle, etree, and more.
> I feel it's the standard message.
>
> Vitaly,
> A lot of objects can't be copied. It's the general case for all kinds of
> objects that hold operating system resources (files, sockets) or wrap
> external C libraries (bz2, lzma, sqlite, ssl). We generally don't document
> that an object cannot be pickled, serialized, or copied. If documentation
> doesn't state that an object is copy-able or doesn't provide a dedicated
> copy method, than it can't be copied.
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue33023>
> _______________________________________
>

Christian, I thought the reason of adding __getstate__ methods which raise an exception is that the existing error message doesn't satisfy your. What is the other reason?

That's the only reason for PR 6099. The change makes it more obvious that SSL objects can't be serialized or copied.

See issue33138.

We have a languishing PR here.  What should be done with it?  If I understand correctly, Serhiy is proposing a more general cleanup in Issue33138 PR 6239.  If that is merged, can PR 6099 here be simplified?  What branches should it apply to? (retargeting for 3.8 pending comments)

The change to the dup() method looks as a bug fix to me. It needs to be backported to all maintained versions. New tests can be backported to all versions except perhaps 2.7 (not tested). Changes to __getstate__() will be not needed if merge issue33138 PR 6239 (they just change the error message). But it may be needed to apply them to 2.7 only.

If changes to __getstate__() be merged in 2.7, I suggest to unify them with issue33138.