[issue38240] assertCountEqual is horribly misleading, sounds like only counts are being compared
Vitaly Kruglikov added the comment: Well, when you do tab-completion in unit tests on `self.` and `assertCountEqual` pops up, it sure sounds a lot like it's going to compare just the count of the items. The point is that the name of the function is not self-documenting, hence "misleading". A better name could be `assertItemsEqual` or `assertCountAndItemsEqual` On Sat, Sep 5, 2020 at 1:02 PM Raymond Hettinger wrote: > > Raymond Hettinger added the comment: > > This should stay closed as a duplicate. > > If you must, reopen of the original 27071, but it was closed for a > reason. The majority of respondents voted for the status quo. Each > alternative that was considered had its own share of problems. > > BTW, it is hyperbolic to call the name "horribly misleading". The method > literally runs Counter and checks for equality. The docstring is clear > about this: > > def assertCountEqual(self, first, second, msg=None): > """Asserts that two iterables have the same elements, the same > number of > times, without regard to order. > > self.assertEqual(Counter(list(first)), > Counter(list(second))) > > Example: > - [0, 1, 1] and [1, 0, 1] compare equal. > - [0, 0, 1] and [0, 1] compare unequal. > > """ > > -- > nosy: +rhettinger > status: open -> closed > > ___ > Python tracker > <https://bugs.python.org/issue38240> > ___ > -- ___ Python tracker <https://bugs.python.org/issue38240> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38240] assertCountEqual is horribly misleading, sounds like only counts are being compared
Vitaly Kruglikov added the comment: Reopened per request from ammar2 -- ___ Python tracker <https://bugs.python.org/issue38240> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38240] assertCountEqual is horribly misleading, sounds like only counts are being compared
Vitaly Kruglikov added the comment: Re-opened, thanks! On Fri, Sep 20, 2019 at 3:01 PM Ammar Askar wrote: > > Ammar Askar added the comment: > > Hey Vitaly, not sure if you're the author of the original bug here: > https://bugs.python.org/issue27071 > > Could you re-open that so the discussion is kept in one place. > > -- > nosy: +ammar2 > > ___ > Python tracker > <https://bugs.python.org/issue38240> > ___ > -- ___ Python tracker <https://bugs.python.org/issue38240> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38240] assertCountEqual is horribly misleading, sounds like only counts are being compared
Change by Vitaly Kruglikov : -- status: closed -> open ___ Python tracker <https://bugs.python.org/issue38240> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38240] assertCountEqual is horribly misleading, sounds like only counts are being compared
New submission from Vitaly Kruglikov : assertCountEqual is a horribly misleading name because it misleads the programmer and reader of the test code into thinking that it only compares the counts of the elements. It's name misrepresents what it does in a really bad way. -- components: Tests messages: 352901 nosy: vitaly.krug priority: normal severity: normal status: open title: assertCountEqual is horribly misleading, sounds like only counts are being compared versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue38240> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33206] Windows inet_pton(socket.AF_INET6, 'localhost') raises ValueError instead of socket.error
Vitaly Kruglikov <vitaly.k...@gmail.com> added the comment: Indeed, confirmed no `inet_pton()` on Windows in Python 2.7 :(. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33206> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33206] Windows inet_pton(socket.AF_INET6, 'localhost') raises ValueError instead of socket.error
Vitaly Kruglikov <vitaly.k...@gmail.com> added the comment: Zachary, thank you for noticing that Twisted is involved. inet_pton definitely exists on Windows 2.7.14, but it turns out that Twisted monkey-patches it if `socket.inet_pton(socket.AF_INET6, "::")` fails. Aha! - but this suggests that Window's Python 2.7.14 implementation of `socket.inet_pton()` has a bug in that it fails to recognize '::' as the the IPv6 unspecified address 0:0:0:0:0:0:0:0, so `socket.inet_pton(socket.AF_INET6, "::")` fails. I wonder if this exists on Windows Python3 implementations? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33206> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33206] Windows inet_pton(socket.AF_INET6, 'localhost') raises ValueError instead of socket.error
Vitaly Kruglikov <vitaly.k...@gmail.com> added the comment: This behavior goes against the socket documentation https://docs.python.org/2/library/socket.html which states "Supported values for address_family are currently AF_INET and AF_INET6. If the IP address string ip_string is invalid, *socket.error* will be raised." -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33206> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33206] Windows inet_pton(socket.AF_INET6, 'localhost') raises ValueError instead of socket.error
Change by Vitaly Kruglikov <vitaly.k...@gmail.com>: -- type: -> behavior ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33206> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33206] Windows inet_pton(socket.AF_INET6, 'localhost') raises ValueError instead of socket.error
New submission from Vitaly Kruglikov <vitaly.k...@gmail.com>:
I am seeing this with `socket.AF_INET6` on Windows running python 2.7.14
```
[00:02:33] File "C:\projects\pika\pika\adapters\host_tcp_connector.py", line
153, in _check_already_resolved
[00:02:33] socket.inet_pton(socket.AF_INET6, 'localhost')
[00:02:33] File "C:\Python27\lib\site-packages\twisted\python\compat.py",
line 68, in inet_pton
[00:02:33] raise ValueError("Illegal characters: %r" % (''.join(x),))
[00:02:33] ValueError: Illegal characters: 't'
```
With `socket.AF_INET`, `socket.inet_pton(socket.AF_INET, 'localhost')` raises
`socket.error` as expected.
For comparison, with Python 2.7.10 running on OS X, both AF_INET and AF_INET6
raise `socket.error`.
--
components: Library (Lib), Windows
messages: 314814
nosy: paul.moore, steve.dower, tim.golden, vitaly.krug, zach.ware
priority: normal
severity: normal
status: open
title: Windows inet_pton(socket.AF_INET6, 'localhost') raises ValueError
instead of socket.error
versions: Python 2.7
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33206>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33148] RuntimeError('Event loop is closed') after cancelling getaddrinfo and closing loop
New submission from Vitaly Kruglikov <vitaly.k...@gmail.com>:
I see this exception on the terminal:
```
exception calling callback for
Traceback (most recent call last):
File
"/usr/local/Cellar/python/3.6.4_3/Frameworks/Python.framework/Versions/3.6/lib/python3.6/concurrent/futures/_base.py",
line 324, in _invoke_callbacks
callback(self)
File
"/usr/local/Cellar/python/3.6.4_3/Frameworks/Python.framework/Versions/3.6/lib/python3.6/asyncio/futures.py",
line 414, in _call_set_state
dest_loop.call_soon_threadsafe(_set_state, destination, source)
File
"/usr/local/Cellar/python/3.6.4_3/Frameworks/Python.framework/Versions/3.6/lib/python3.6/asyncio/base_events.py",
line 620, in call_soon_threadsafe
self._check_closed()
File
"/usr/local/Cellar/python/3.6.4_3/Frameworks/Python.framework/Versions/3.6/lib/python3.6/asyncio/base_events.py",
line 357, in _check_closed
raise RuntimeError('Event loop is closed')
RuntimeError: Event loop is closed
```
When executing this code:
```
import asyncio
while True:
loop = asyncio.new_event_loop()
coro = loop.getaddrinfo('www.google.com', 80)
task = asyncio.ensure_future(coro, loop=loop)
task.cancel()
loop.call_soon_threadsafe(loop.stop)
loop.run_forever()
loop.close()
```
Shouldn't a cancelled operation go away (or at least pretend to go away)
cleanly?
--
components: asyncio
messages: 314484
nosy: asvetlov, vitaly.krug, yselivanov
priority: normal
severity: normal
status: open
title: RuntimeError('Event loop is closed') after cancelling getaddrinfo and
closing loop
versions: Python 3.6
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33148>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33023] Unable to copy ssl.SSLContext
Vitaly Kruglikov <vitaly.k...@gmail.com> added the comment: Thank you, I'll consider myself having been warned :) On Sat, Mar 24, 2018, 7:28 AM Christian Heimes <rep...@bugs.python.org> wrote: > > Christian Heimes <li...@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 <rep...@bugs.python.org> > <https://bugs.python.org/issue33023> > ___ > -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33023> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33023] Unable to copy ssl.SSLContext
Vitaly Kruglikov <vitaly.k...@gmail.com> added the comment: 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. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33023> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33118] No clean way to get notified when a Transport's write buffer empties out
Vitaly Kruglikov <vitaly.k...@gmail.com> added the comment: Yet another paradigm is the likes of `GSource` in gnome's glib. GSource "tasks" added to the event loop are polled by the event loop for readiness before the event loop blocks on select/epoll/etc.. The ones that are ready are removed from the loop and their callbacks are dispatched. I suppose that it would also be difficult to get buy-in for a feature like this from the different frameworks? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33118> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33118] No clean way to get notified when a Transport's write buffer empties out
Vitaly Kruglikov <vitaly.k...@gmail.com> added the comment: I'll have to settle for `set_write_buffer_limits(0, 0)` for my blocking wrapper case. I think that 'write_buffer_drained' callback is a good idea, though. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33118> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33118] No clean way to get notified when a Transport's write buffer empties out
Vitaly Kruglikov <vitaly.k...@gmail.com> added the comment: > 'events.AbstractEventLoop.run_one_step()' > This is highly unlikely to ever happen. Sure, I can see how that could be a problem with other underlying implementations, such as Twisted reactor. Just wishful thinking :). -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33118> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33118] No clean way to get notified when a Transport's write buffer empties out
Vitaly Kruglikov <vitaly.k...@gmail.com> added the comment: ... or `events.AbstractEventLoop.run_one_iteration()`. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33118> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33118] No clean way to get notified when a Transport's write buffer empties out
Vitaly Kruglikov <vitaly.k...@gmail.com> added the comment: Thank you for following up. My use case is this: In the Pika AMQP client package, we have a blocking AMQP connection adapter - `BlockingConnection` - wrapped around an asynchronous AMQP connection adapter. Presently, BlockingConnection is wrapped around the asynchronous `SelectConnection` which has a home-grown proprietary IOLoop. I would like to switch BlockingConnection to use an asyncio-based adapter when running on Python3. SelectConnection's proprietary IOLoop provides a single-stepping run function (poll with a timeout as normally determined by pending callbacks, timers, etc., process all ready events/timers/callbacks, and return). When BlockingConnection needs to send something to the AMQP broker and/or wait for an expected reply, it sends the request (which typically gets queued up in a write buffer) and then runs the proprietary IOLoop's single-stepping method in a loop (thus blocking efficiently on I/O); each time after the single-stepping IOLoop method returns, BlockingConnection checks whether the conditions of interest have been satisfied (e.g., the write buffer size being zero and AMQP Channel.OpenOk has been received). So, another way that asyncio could help, and certainly simplest for me and my use case, is by providing a single-stepping function in the event loop implementations, such as the single-stepping method that I described at the top of the previous paragraph. E.g., `events.AbstractEventLoop.run_one_step()`. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33118> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33118] No clean way to get notified when a Transport's write buffer empties out
New submission from Vitaly Kruglikov <vitaly.k...@gmail.com>: There doesn't appear to be an ordained mechanism for getting notified when a Transport's (or WriteTransport's) write buffer drains to zero (i.e., all output data has been transferred to socket). I don't want to hijack `set_write_buffer_limits()` for this purpose, because that would preclude me from using it for its intended purpose. I see that transport in selector_events.py has a private method `_make_empty_waiter()`, which is along the lines of what I need, but it's private and is used by `BaseSelectorEventLoop._sendfile_native()`. Just like `BaseSelectorEventLoop._sendfile_native()`, my app needs equivalent functionality in order to be able to run the loop (`run_until_complete()`) until the transport's write buffer empties out. -- components: asyncio messages: 314236 nosy: asvetlov, vitaly.krug, yselivanov priority: normal severity: normal status: open title: No clean way to get notified when a Transport's write buffer empties out type: enhancement versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33118> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33062] ssl_renegotiate() doesn't seem to be exposed
Vitaly Kruglikov <vitaly.k...@gmail.com> added the comment: > For extra fun, openssl itself doesn't fully support renegotiation on duplex > connections ... The necessitated modification to the application protocol on that thread sounds like an OpenSSL cop-out. There is no good reason that OpenSSL shouldn't be able to cache incoming application data during the client-initiated handshake just as it does at other times. It should be able to cache the incoming pre-negotiation records, decoding them. The pending() check would inform the client that they need to reap the incoming data during the handshake too. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33062> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33062] ssl_renegotiate() doesn't seem to be exposed
Vitaly Kruglikov <vitaly.k...@gmail.com> added the comment: > By the way, renegotiation is a problematic and has been replaced by rekeying > in TLS 1.3 How can I trigger rekeying via python ssl? Many thanks. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33062> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33062] ssl_renegotiate() doesn't seem to be exposed
New submission from Vitaly Kruglikov <vitaly.k...@gmail.com>: I need to write a test for my client to make sure it's non-blocking ssl interactions are able to survive SSL renegotiation. However, I can't seem to find anything in our python ssl API that calls `SSL_renegotiate()` in order to force renegotiation. -- assignee: christian.heimes components: SSL messages: 313706 nosy: christian.heimes, vitaly.krug priority: normal severity: normal status: open title: ssl_renegotiate() doesn't seem to be exposed type: behavior versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33062> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33023] Unable to copy ssl.SSLContext
Vitaly Kruglikov <vitaly.k...@gmail.com> added the comment: > 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. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33023> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33023] Unable to copy ssl.SSLContext
Vitaly Kruglikov <vitaly.k...@gmail.com> added the comment: 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! -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33023> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33023] Unable to copy ssl.SSLContext
Vitaly Kruglikov <vitaly.k...@gmail.com> added the comment: 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? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33023> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33025] urlencode produces bad output from ssl.CERT_NONE and friends that chokes decoders
New submission from Vitaly Kruglikov <vitaly.k...@gmail.com>:
```
In [9]: from urllib.parse import urlencode, parse_qs
In [10]: import ast, ssl
In [11]: d = dict(cert_reqs=ssl.CERT_NONE)
In [12]: urlencode(d)
Out[12]: 'cert_reqs=VerifyMode.CERT_NONE'
In [25]: parse_qs('cert_reqs=VerifyMode.CERT_NONE')
Out[25]: {'cert_reqs': ['VerifyMode.CERT_NONE']}
In [29]: ast.literal_eval('VerifyMode.CERT_NONE')
Traceback (most recent call last)
...
ValueError: malformed node or string: <_ast.Attribute object at 0x105c22358>
```
This used to work fine and produce `'cert_reqs=0'` on Python 2.7, allowing it
to be decoded properly downstream. However, `'cert_reqs=VerifyMode.CERT_NONE'`
can't be decoded generically. So, something it's that used to work in prior
python versions that is breaking now.
Additional information. json.dumps() actually dumps that value as a number
instead of 'VerifyMode.CERT_NONE'.
It appears that urlencode doesn't work properly with enums, where I would
expect it to emit the numeric value of the enum.
--
assignee: christian.heimes
components: Library (Lib), SSL
messages: 313424
nosy: christian.heimes, vitaly.krug
priority: normal
severity: normal
status: open
title: urlencode produces bad output from ssl.CERT_NONE and friends that chokes
decoders
type: crash
versions: Python 3.6, Python 3.7
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33025>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33024] asyncio.WriteTransport.set_write_buffer_limits orders its args unintuitively and inconsistently with its companion function's return value
New submission from Vitaly Kruglikov <vitaly.k...@gmail.com>: `asyncio.WriteTransport.set_write_buffer_limits()` uses an unintuitive order of the args (high, low). I would expect `low` to be the first arg, especially since `asyncio.WriteTransport.get_write_buffer_limits()` returns them in the opposite order. This ordering and inconsistency with the companion function's return value is error-prone. See https://docs.python.org/3/library/asyncio-protocol.html#asyncio.WriteTransport.set_write_buffer_limits -- components: asyncio messages: 313423 nosy: asvetlov, vitaly.krug, yselivanov priority: normal severity: normal status: open title: asyncio.WriteTransport.set_write_buffer_limits orders its args unintuitively and inconsistently with its companion function's return value type: behavior versions: Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33024> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33023] Unable to copy ssl.SSLContext
Change by Vitaly Kruglikov <vitaly.k...@gmail.com>: -- assignee: -> christian.heimes components: +SSL nosy: +christian.heimes ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33023> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33023] Unable to copy ssl.SSLContext
New submission from Vitaly Kruglikov <vitaly.k...@gmail.com>: ``` 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. -- messages: 313422 nosy: vitaly.krug priority: normal severity: normal status: open title: Unable to copy ssl.SSLContext versions: Python 2.7, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33023> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33023] Unable to copy ssl.SSLContext
Change by Vitaly Kruglikov <vitaly.k...@gmail.com>: -- type: -> crash ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33023> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
