Victor Stinner | db39a0d | 2014-01-16 18:58:01 +0100 | [diff] [blame] | 1 | .. currentmodule:: asyncio |
| 2 | |
Victor Stinner | 0f3e6bc | 2014-02-19 23:15:02 +0100 | [diff] [blame] | 3 | .. _asyncio-dev: |
| 4 | |
Victor Stinner | db39a0d | 2014-01-16 18:58:01 +0100 | [diff] [blame] | 5 | Develop with asyncio |
| 6 | ==================== |
| 7 | |
| 8 | Asynchronous programming is different than classical "sequential" programming. |
Eli Bendersky | 679688e | 2014-01-20 08:13:31 -0800 | [diff] [blame] | 9 | This page lists common traps and explains how to avoid them. |
Victor Stinner | db39a0d | 2014-01-16 18:58:01 +0100 | [diff] [blame] | 10 | |
| 11 | |
Victor Stinner | 62511fd | 2014-06-23 00:36:11 +0200 | [diff] [blame] | 12 | .. _asyncio-debug-mode: |
| 13 | |
| 14 | Debug mode of asyncio |
| 15 | --------------------- |
| 16 | |
| 17 | To enable the debug mode globally, set the environment variable |
Victor Stinner | d71dcbb | 2014-08-25 17:04:12 +0200 | [diff] [blame] | 18 | :envvar:`PYTHONASYNCIODEBUG` to ``1``. To see debug traces, set the log level |
| 19 | of the :ref:`asyncio logger <asyncio-logger>` to :py:data:`logging.DEBUG`. The |
| 20 | simplest configuration is:: |
| 21 | |
| 22 | import logging |
| 23 | # ... |
| 24 | logging.basicConfig(level=logging.DEBUG) |
| 25 | |
| 26 | Examples of effects of the debug mode: |
Victor Stinner | 62511fd | 2014-06-23 00:36:11 +0200 | [diff] [blame] | 27 | |
| 28 | * Log :ref:`coroutines defined but never "yielded from" |
| 29 | <asyncio-coroutine-not-scheduled>` |
| 30 | * :meth:`~BaseEventLoop.call_soon` and :meth:`~BaseEventLoop.call_at` methods |
| 31 | raise an exception if they are called from the wrong thread. |
| 32 | * Log the execution time of the selector |
| 33 | * Log callbacks taking more than 100 ms to be executed. The |
| 34 | :attr:`BaseEventLoop.slow_callback_duration` attribute is the minimum |
| 35 | duration in seconds of "slow" callbacks. |
| 36 | |
| 37 | .. seealso:: |
| 38 | |
| 39 | The :meth:`BaseEventLoop.set_debug` method and the :ref:`asyncio logger |
| 40 | <asyncio-logger>`. |
| 41 | |
| 42 | |
Victor Stinner | 1077dee | 2015-01-30 00:55:58 +0100 | [diff] [blame] | 43 | Cancellation |
| 44 | ------------ |
| 45 | |
| 46 | Cancellation of tasks is not common in classic programming. In asynchronous |
| 47 | programming, not only it is something common, but you have to prepare your |
| 48 | code to handle it. |
| 49 | |
| 50 | Futures and tasks can be cancelled explicitly with their :meth:`Future.cancel` |
| 51 | method. The :func:`wait_for` function cancels the waited task when the timeout |
| 52 | occurs. There are many other cases where a task can be cancelled indirectly. |
| 53 | |
| 54 | Don't call :meth:`~Future.set_result` or :meth:`~Future.set_exception` method |
| 55 | of :class:`Future` if the future is cancelled: it would fail with an exception. |
| 56 | For example, write:: |
| 57 | |
| 58 | if not fut.cancelled(): |
| 59 | fut.set_result('done') |
| 60 | |
| 61 | Don't schedule directly a call to the :meth:`~Future.set_result` or the |
| 62 | :meth:`~Future.set_exception` method of a future with |
| 63 | :meth:`BaseEventLoop.call_soon`: the future can be cancelled before its method |
| 64 | is called. |
| 65 | |
| 66 | If you wait for a future, you should check early if the future was cancelled to |
| 67 | avoid useless operations. Example:: |
| 68 | |
| 69 | @coroutine |
| 70 | def slow_operation(fut): |
| 71 | if fut.cancelled(): |
| 72 | return |
| 73 | # ... slow computation ... |
| 74 | yield from fut |
| 75 | # ... |
| 76 | |
| 77 | The :func:`shield` function can also be used to ignore cancellation. |
| 78 | |
| 79 | |
Victor Stinner | 606ab03 | 2014-02-01 03:18:58 +0100 | [diff] [blame] | 80 | .. _asyncio-multithreading: |
| 81 | |
| 82 | Concurrency and multithreading |
| 83 | ------------------------------ |
| 84 | |
| 85 | An event loop runs in a thread and executes all callbacks and tasks in the same |
Victor Stinner | 86516d9 | 2014-02-18 09:22:00 +0100 | [diff] [blame] | 86 | thread. While a task is running in the event loop, no other task is running in |
Victor Stinner | 5cb84ed | 2014-02-04 18:18:27 +0100 | [diff] [blame] | 87 | the same thread. But when the task uses ``yield from``, the task is suspended |
| 88 | and the event loop executes the next task. |
Victor Stinner | 606ab03 | 2014-02-01 03:18:58 +0100 | [diff] [blame] | 89 | |
Victor Stinner | 5cb84ed | 2014-02-04 18:18:27 +0100 | [diff] [blame] | 90 | To schedule a callback from a different thread, the |
| 91 | :meth:`BaseEventLoop.call_soon_threadsafe` method should be used. Example to |
Guido van Rossum | 3c9bb69 | 2014-02-04 13:49:34 -0800 | [diff] [blame] | 92 | schedule a coroutine from a different thread:: |
Victor Stinner | 5cb84ed | 2014-02-04 18:18:27 +0100 | [diff] [blame] | 93 | |
| 94 | loop.call_soon_threadsafe(asyncio.async, coro_func()) |
Victor Stinner | 606ab03 | 2014-02-01 03:18:58 +0100 | [diff] [blame] | 95 | |
Victor Stinner | 790202d | 2014-02-07 19:03:05 +0100 | [diff] [blame] | 96 | Most asyncio objects are not thread safe. You should only worry if you access |
| 97 | objects outside the event loop. For example, to cancel a future, don't call |
| 98 | directly its :meth:`Future.cancel` method, but:: |
| 99 | |
| 100 | loop.call_soon_threadsafe(fut.cancel) |
| 101 | |
Victor Stinner | 606ab03 | 2014-02-01 03:18:58 +0100 | [diff] [blame] | 102 | To handle signals and to execute subprocesses, the event loop must be run in |
| 103 | the main thread. |
| 104 | |
| 105 | The :meth:`BaseEventLoop.run_in_executor` method can be used with a thread pool |
| 106 | executor to execute a callback in different thread to not block the thread of |
| 107 | the event loop. |
| 108 | |
| 109 | .. seealso:: |
| 110 | |
Zachary Ware | 5819cfa | 2015-01-06 00:40:43 -0600 | [diff] [blame] | 111 | The :ref:`Synchronization primitives <asyncio-sync>` section describes ways |
| 112 | to synchronize tasks. |
Victor Stinner | 606ab03 | 2014-02-01 03:18:58 +0100 | [diff] [blame] | 113 | |
Victor Stinner | 399c59d | 2015-01-09 01:32:02 +0100 | [diff] [blame] | 114 | The :ref:`Subprocess and threads <asyncio-subprocess-threads>` section lists |
| 115 | asyncio limitations to run subprocesses from different threads. |
| 116 | |
| 117 | |
| 118 | |
Victor Stinner | 606ab03 | 2014-02-01 03:18:58 +0100 | [diff] [blame] | 119 | |
Victor Stinner | 45b27ed | 2014-02-01 02:36:43 +0100 | [diff] [blame] | 120 | .. _asyncio-handle-blocking: |
| 121 | |
Eli Bendersky | b73c833 | 2014-02-09 06:07:47 -0800 | [diff] [blame] | 122 | Handle blocking functions correctly |
Victor Stinner | db39a0d | 2014-01-16 18:58:01 +0100 | [diff] [blame] | 123 | ----------------------------------- |
| 124 | |
| 125 | Blocking functions should not be called directly. For example, if a function |
| 126 | blocks for 1 second, other tasks are delayed by 1 second which can have an |
| 127 | important impact on reactivity. |
| 128 | |
| 129 | For networking and subprocesses, the :mod:`asyncio` module provides high-level |
Victor Stinner | 9592edb | 2014-02-02 15:03:02 +0100 | [diff] [blame] | 130 | APIs like :ref:`protocols <asyncio-protocol>`. |
Victor Stinner | db39a0d | 2014-01-16 18:58:01 +0100 | [diff] [blame] | 131 | |
| 132 | An executor can be used to run a task in a different thread or even in a |
| 133 | different process, to not block the thread of the event loop. See the |
Victor Stinner | 606ab03 | 2014-02-01 03:18:58 +0100 | [diff] [blame] | 134 | :meth:`BaseEventLoop.run_in_executor` method. |
Victor Stinner | db39a0d | 2014-01-16 18:58:01 +0100 | [diff] [blame] | 135 | |
Victor Stinner | 45b27ed | 2014-02-01 02:36:43 +0100 | [diff] [blame] | 136 | .. seealso:: |
| 137 | |
| 138 | The :ref:`Delayed calls <asyncio-delayed-calls>` section details how the |
| 139 | event loop handles time. |
| 140 | |
Victor Stinner | db39a0d | 2014-01-16 18:58:01 +0100 | [diff] [blame] | 141 | |
| 142 | .. _asyncio-logger: |
| 143 | |
Victor Stinner | 45b27ed | 2014-02-01 02:36:43 +0100 | [diff] [blame] | 144 | Logging |
| 145 | ------- |
Victor Stinner | db39a0d | 2014-01-16 18:58:01 +0100 | [diff] [blame] | 146 | |
Victor Stinner | 45b27ed | 2014-02-01 02:36:43 +0100 | [diff] [blame] | 147 | The :mod:`asyncio` module logs information with the :mod:`logging` module in |
| 148 | the logger ``'asyncio'``. |
Victor Stinner | db39a0d | 2014-01-16 18:58:01 +0100 | [diff] [blame] | 149 | |
Victor Stinner | db39a0d | 2014-01-16 18:58:01 +0100 | [diff] [blame] | 150 | |
| 151 | .. _asyncio-coroutine-not-scheduled: |
| 152 | |
| 153 | Detect coroutine objects never scheduled |
| 154 | ---------------------------------------- |
| 155 | |
Victor Stinner | 530ef2f | 2014-07-08 12:39:10 +0200 | [diff] [blame] | 156 | When a coroutine function is called and its result is not passed to |
Zachary Ware | 5819cfa | 2015-01-06 00:40:43 -0600 | [diff] [blame] | 157 | :func:`async` or to the :meth:`BaseEventLoop.create_task` method, the execution |
| 158 | of the coroutine object will never be scheduled which is probably a bug. |
Victor Stinner | 530ef2f | 2014-07-08 12:39:10 +0200 | [diff] [blame] | 159 | :ref:`Enable the debug mode of asyncio <asyncio-debug-mode>` to :ref:`log a |
| 160 | warning <asyncio-logger>` to detect it. |
Victor Stinner | db39a0d | 2014-01-16 18:58:01 +0100 | [diff] [blame] | 161 | |
| 162 | Example with the bug:: |
| 163 | |
| 164 | import asyncio |
Victor Stinner | db39a0d | 2014-01-16 18:58:01 +0100 | [diff] [blame] | 165 | |
| 166 | @asyncio.coroutine |
| 167 | def test(): |
| 168 | print("never scheduled") |
| 169 | |
| 170 | test() |
| 171 | |
| 172 | Output in debug mode:: |
| 173 | |
Victor Stinner | 530ef2f | 2014-07-08 12:39:10 +0200 | [diff] [blame] | 174 | Coroutine test() at test.py:3 was never yielded from |
| 175 | Coroutine object created at (most recent call last): |
| 176 | File "test.py", line 7, in <module> |
| 177 | test() |
Victor Stinner | db39a0d | 2014-01-16 18:58:01 +0100 | [diff] [blame] | 178 | |
Victor Stinner | 530ef2f | 2014-07-08 12:39:10 +0200 | [diff] [blame] | 179 | The fix is to call the :func:`async` function or the |
| 180 | :meth:`BaseEventLoop.create_task` method with the coroutine object. |
| 181 | |
| 182 | .. seealso:: |
| 183 | |
| 184 | :ref:`Pending task destroyed <asyncio-pending-task-destroyed>`. |
Victor Stinner | db39a0d | 2014-01-16 18:58:01 +0100 | [diff] [blame] | 185 | |
| 186 | |
Victor Stinner | 530ef2f | 2014-07-08 12:39:10 +0200 | [diff] [blame] | 187 | Detect exceptions never consumed |
| 188 | -------------------------------- |
Victor Stinner | db39a0d | 2014-01-16 18:58:01 +0100 | [diff] [blame] | 189 | |
| 190 | Python usually calls :func:`sys.displayhook` on unhandled exceptions. If |
Victor Stinner | 530ef2f | 2014-07-08 12:39:10 +0200 | [diff] [blame] | 191 | :meth:`Future.set_exception` is called, but the exception is never consumed, |
Zachary Ware | 5819cfa | 2015-01-06 00:40:43 -0600 | [diff] [blame] | 192 | :func:`sys.displayhook` is not called. Instead, :ref:`a log is emitted |
Victor Stinner | 530ef2f | 2014-07-08 12:39:10 +0200 | [diff] [blame] | 193 | <asyncio-logger>` when the future is deleted by the garbage collector, with the |
| 194 | traceback where the exception was raised. |
Victor Stinner | db39a0d | 2014-01-16 18:58:01 +0100 | [diff] [blame] | 195 | |
| 196 | Example of unhandled exception:: |
| 197 | |
| 198 | import asyncio |
| 199 | |
| 200 | @asyncio.coroutine |
| 201 | def bug(): |
| 202 | raise Exception("not consumed") |
| 203 | |
| 204 | loop = asyncio.get_event_loop() |
| 205 | asyncio.async(bug()) |
| 206 | loop.run_forever() |
| 207 | |
| 208 | Output:: |
| 209 | |
Victor Stinner | 530ef2f | 2014-07-08 12:39:10 +0200 | [diff] [blame] | 210 | Task exception was never retrieved |
Victor Stinner | ab1c853 | 2014-10-12 21:37:16 +0200 | [diff] [blame] | 211 | future: <Task finished coro=<coro() done, defined at asyncio/coroutines.py:139> exception=Exception('not consumed',)> |
Victor Stinner | db39a0d | 2014-01-16 18:58:01 +0100 | [diff] [blame] | 212 | Traceback (most recent call last): |
Victor Stinner | ab1c853 | 2014-10-12 21:37:16 +0200 | [diff] [blame] | 213 | File "asyncio/tasks.py", line 237, in _step |
Victor Stinner | db39a0d | 2014-01-16 18:58:01 +0100 | [diff] [blame] | 214 | result = next(coro) |
Victor Stinner | 530ef2f | 2014-07-08 12:39:10 +0200 | [diff] [blame] | 215 | File "asyncio/coroutines.py", line 141, in coro |
Victor Stinner | db39a0d | 2014-01-16 18:58:01 +0100 | [diff] [blame] | 216 | res = func(*args, **kw) |
Victor Stinner | ab1c853 | 2014-10-12 21:37:16 +0200 | [diff] [blame] | 217 | File "test.py", line 5, in bug |
Victor Stinner | db39a0d | 2014-01-16 18:58:01 +0100 | [diff] [blame] | 218 | raise Exception("not consumed") |
| 219 | Exception: not consumed |
| 220 | |
Victor Stinner | 530ef2f | 2014-07-08 12:39:10 +0200 | [diff] [blame] | 221 | :ref:`Enable the debug mode of asyncio <asyncio-debug-mode>` to get the |
Victor Stinner | ab1c853 | 2014-10-12 21:37:16 +0200 | [diff] [blame] | 222 | traceback where the task was created. Output in debug mode:: |
| 223 | |
| 224 | Task exception was never retrieved |
| 225 | future: <Task finished coro=<bug() done, defined at test.py:3> exception=Exception('not consumed',) created at test.py:8> |
| 226 | source_traceback: Object created at (most recent call last): |
| 227 | File "test.py", line 8, in <module> |
| 228 | asyncio.async(bug()) |
| 229 | Traceback (most recent call last): |
| 230 | File "asyncio/tasks.py", line 237, in _step |
| 231 | result = next(coro) |
| 232 | File "asyncio/coroutines.py", line 79, in __next__ |
| 233 | return next(self.gen) |
| 234 | File "asyncio/coroutines.py", line 141, in coro |
| 235 | res = func(*args, **kw) |
| 236 | File "test.py", line 5, in bug |
| 237 | raise Exception("not consumed") |
| 238 | Exception: not consumed |
Victor Stinner | 530ef2f | 2014-07-08 12:39:10 +0200 | [diff] [blame] | 239 | |
Zachary Ware | 5819cfa | 2015-01-06 00:40:43 -0600 | [diff] [blame] | 240 | There are different options to fix this issue. The first option is to chain the |
Victor Stinner | db39a0d | 2014-01-16 18:58:01 +0100 | [diff] [blame] | 241 | coroutine in another coroutine and use classic try/except:: |
| 242 | |
| 243 | @asyncio.coroutine |
| 244 | def handle_exception(): |
| 245 | try: |
| 246 | yield from bug() |
| 247 | except Exception: |
| 248 | print("exception consumed") |
| 249 | |
| 250 | loop = asyncio.get_event_loop() |
| 251 | asyncio.async(handle_exception()) |
| 252 | loop.run_forever() |
| 253 | |
| 254 | Another option is to use the :meth:`BaseEventLoop.run_until_complete` |
| 255 | function:: |
| 256 | |
| 257 | task = asyncio.async(bug()) |
| 258 | try: |
| 259 | loop.run_until_complete(task) |
| 260 | except Exception: |
| 261 | print("exception consumed") |
| 262 | |
Zachary Ware | 5819cfa | 2015-01-06 00:40:43 -0600 | [diff] [blame] | 263 | .. seealso:: |
| 264 | |
| 265 | The :meth:`Future.exception` method. |
Victor Stinner | db39a0d | 2014-01-16 18:58:01 +0100 | [diff] [blame] | 266 | |
| 267 | |
Zachary Ware | 5819cfa | 2015-01-06 00:40:43 -0600 | [diff] [blame] | 268 | Chain coroutines correctly |
Victor Stinner | db39a0d | 2014-01-16 18:58:01 +0100 | [diff] [blame] | 269 | -------------------------- |
| 270 | |
| 271 | When a coroutine function calls other coroutine functions and tasks, they |
Eli Bendersky | 679688e | 2014-01-20 08:13:31 -0800 | [diff] [blame] | 272 | should be chained explicitly with ``yield from``. Otherwise, the execution is |
| 273 | not guaranteed to be sequential. |
Victor Stinner | db39a0d | 2014-01-16 18:58:01 +0100 | [diff] [blame] | 274 | |
Eli Bendersky | 679688e | 2014-01-20 08:13:31 -0800 | [diff] [blame] | 275 | Example with different bugs using :func:`asyncio.sleep` to simulate slow |
| 276 | operations:: |
Victor Stinner | db39a0d | 2014-01-16 18:58:01 +0100 | [diff] [blame] | 277 | |
| 278 | import asyncio |
| 279 | |
| 280 | @asyncio.coroutine |
| 281 | def create(): |
| 282 | yield from asyncio.sleep(3.0) |
| 283 | print("(1) create file") |
| 284 | |
| 285 | @asyncio.coroutine |
| 286 | def write(): |
| 287 | yield from asyncio.sleep(1.0) |
| 288 | print("(2) write into file") |
| 289 | |
| 290 | @asyncio.coroutine |
| 291 | def close(): |
| 292 | print("(3) close file") |
| 293 | |
| 294 | @asyncio.coroutine |
| 295 | def test(): |
| 296 | asyncio.async(create()) |
| 297 | asyncio.async(write()) |
| 298 | asyncio.async(close()) |
| 299 | yield from asyncio.sleep(2.0) |
| 300 | loop.stop() |
| 301 | |
| 302 | loop = asyncio.get_event_loop() |
| 303 | asyncio.async(test()) |
| 304 | loop.run_forever() |
| 305 | print("Pending tasks at exit: %s" % asyncio.Task.all_tasks(loop)) |
Victor Stinner | f40c663 | 2014-01-28 23:32:40 +0100 | [diff] [blame] | 306 | loop.close() |
Victor Stinner | db39a0d | 2014-01-16 18:58:01 +0100 | [diff] [blame] | 307 | |
| 308 | Expected output:: |
| 309 | |
| 310 | (1) create file |
| 311 | (2) write into file |
| 312 | (3) close file |
| 313 | Pending tasks at exit: set() |
| 314 | |
| 315 | Actual output:: |
| 316 | |
| 317 | (3) close file |
| 318 | (2) write into file |
Victor Stinner | 530ef2f | 2014-07-08 12:39:10 +0200 | [diff] [blame] | 319 | Pending tasks at exit: {<Task pending create() at test.py:7 wait_for=<Future pending cb=[Task._wakeup()]>>} |
| 320 | Task was destroyed but it is pending! |
| 321 | task: <Task pending create() done at test.py:5 wait_for=<Future pending cb=[Task._wakeup()]>> |
Victor Stinner | db39a0d | 2014-01-16 18:58:01 +0100 | [diff] [blame] | 322 | |
| 323 | The loop stopped before the ``create()`` finished, ``close()`` has been called |
| 324 | before ``write()``, whereas coroutine functions were called in this order: |
| 325 | ``create()``, ``write()``, ``close()``. |
| 326 | |
| 327 | To fix the example, tasks must be marked with ``yield from``:: |
| 328 | |
| 329 | @asyncio.coroutine |
| 330 | def test(): |
| 331 | yield from asyncio.async(create()) |
| 332 | yield from asyncio.async(write()) |
| 333 | yield from asyncio.async(close()) |
| 334 | yield from asyncio.sleep(2.0) |
| 335 | loop.stop() |
| 336 | |
| 337 | Or without ``asyncio.async()``:: |
| 338 | |
| 339 | @asyncio.coroutine |
| 340 | def test(): |
| 341 | yield from create() |
| 342 | yield from write() |
| 343 | yield from close() |
| 344 | yield from asyncio.sleep(2.0) |
| 345 | loop.stop() |
| 346 | |
Victor Stinner | 530ef2f | 2014-07-08 12:39:10 +0200 | [diff] [blame] | 347 | |
| 348 | .. _asyncio-pending-task-destroyed: |
| 349 | |
| 350 | Pending task destroyed |
| 351 | ---------------------- |
| 352 | |
| 353 | If a pending task is destroyed, the execution of its wrapped :ref:`coroutine |
| 354 | <coroutine>` did not complete. It is probably a bug and so a warning is logged. |
| 355 | |
| 356 | Example of log:: |
| 357 | |
| 358 | Task was destroyed but it is pending! |
Victor Stinner | ab1c853 | 2014-10-12 21:37:16 +0200 | [diff] [blame] | 359 | task: <Task pending coro=<kill_me() done, defined at test.py:5> wait_for=<Future pending cb=[Task._wakeup()]>> |
Victor Stinner | 530ef2f | 2014-07-08 12:39:10 +0200 | [diff] [blame] | 360 | |
| 361 | :ref:`Enable the debug mode of asyncio <asyncio-debug-mode>` to get the |
Victor Stinner | ab1c853 | 2014-10-12 21:37:16 +0200 | [diff] [blame] | 362 | traceback where the task was created. Example of log in debug mode:: |
| 363 | |
| 364 | Task was destroyed but it is pending! |
| 365 | source_traceback: Object created at (most recent call last): |
| 366 | File "test.py", line 15, in <module> |
| 367 | task = asyncio.async(coro, loop=loop) |
| 368 | task: <Task pending coro=<kill_me() done, defined at test.py:5> wait_for=<Future pending cb=[Task._wakeup()] created at test.py:7> created at test.py:15> |
| 369 | |
Victor Stinner | 530ef2f | 2014-07-08 12:39:10 +0200 | [diff] [blame] | 370 | |
| 371 | .. seealso:: |
| 372 | |
| 373 | :ref:`Detect coroutine objects never scheduled <asyncio-coroutine-not-scheduled>`. |
| 374 | |
Victor Stinner | 188f2c0 | 2015-01-30 01:35:14 +0100 | [diff] [blame] | 375 | |
| 376 | Close transports |
| 377 | ---------------- |
| 378 | |
| 379 | When a transport is no more needed, call its ``close()`` method to release |
| 380 | resources. |
| 381 | |
| 382 | If a transport (or an event loop) is not closed explicitly, a |
| 383 | :exc:`ResourceWarning` warning will be emitted in its destructor. The |
| 384 | :exc:`ResourceWarning` warnings are hidden by default: use the ``-Wd`` command |
| 385 | line option of Python to show them. |