This will address the common mistake many asyncio users make:
an "except Exception" clause breaking Tasks cancellation.
In addition to this change, we stop inheriting asyncio.TimeoutError
and asyncio.InvalidStateError from their concurrent.futures.*
counterparts. There's no point for these exceptions to share the
inheritance chain.
In 3.9 we'll focus on implementing supervisors and cancel scopes,
which should allow better handling of all exceptions, including
SystemExit and KeyboardInterrupt
* sys.unraisablehook: add 'err_msg' field to UnraisableHookArgs.
* Use _PyErr_WriteUnraisableMsg() in _ctypes _DictRemover_call()
and gc delete_garbage().
* No type cache for types with specialized mro, invalidation is hard.
* FIX: Don't disable method cache custom types that do not implement mro().
* fixing implem.
* Avoid storing error flags, also decref.
* news entry
* Clear as soon as we're getting an error.
* FIX: Reference leak.
The implementation is straightforward, it just mimics `ClassVar` (since the latter is also a name/access qualifier, not really a type). Also it is essentially copied from `typing_extensions`.
Update PyObject_CallMethodObjArgs and _PyObject_CallMethodIdObjArgs
to use _PyObject_GetMethod to avoid creating a bound method object
in many cases.
On a microbenchmark of PyObject_CallMethodObjArgs calling a method on
an interpreted Python class, this optimization resulted in a 1.7x
speedup.
* 📝 Add a GitHub-specific security page
It will show up @
https://github.com/python/cpython/security/policy
allowing to navigate users who get there from "Security" tab in the
GitHub repo to the full article explaining the security vulnerability
reporting practices.
Co-Authored-By: Hugo <hugovk@users.noreply.github.com>
It is also possible to link against a library or executable with a
statically linked libpython, but not both with the same DLL. In fact
building a statically linked python is currently broken on Cygwin
for other (related) reasons.
The same problem applies to other POSIX-like layers over Windows
(MinGW, MSYS) but Python's build system does not seem to attempt
to support those platforms at the moment.
PyOS_AfterFork_Child(): _PyInterpreterState_DeleteExceptMain() must
be called after _PyRuntimeState_ReInitThreads().
_PyRuntimeState_ReInitThreads() resets interpreters mutex after fork,
mutex used by _PyInterpreterState_DeleteExceptMain().
Remove main_thread and main_interp variables from signalmodule.c:
reuse _PyRuntime which already track the main thread and the main
interpreter.
* Remove #include <sys/types.h> which became useless: getpid() call
has been removed.
* Add runtime argument to is_main()
* is_main() now gets the interpreter from runtime.
Previously, it was hard to tell whether a function should be awaited. It was also incorrect (per PEP 484) to put this in the type hint for coroutine functions. Added this info to the output of builtins.help and pydoc.
https://bugs.python.org/issue36045
bpo-34626: Document creating heap types from the C-API
Add missing descriptions of PEP384's PyType_Spec and PyType_Slot,
along with some introductory prose.