[issue42242] Backport SQLite trace API v2

Samuel Marks added the comment: Done, thanks for the how-to: - https://github.com/python/cpython/pull/23103 [3.8] - https://github.com/python/cpython/pull/23102 [3.9] -- ___ Python tracker __

[issue42242] Backport SQLite trace API v2

Dong-hee Na added the comment: We often submit the backported patch by using the backport label from the origin PR. (https://github.com/python/cpython/pull/19581) So please discuss the backporting on bpo-40318 -- nosy: +corona10 resolution: -> duplicate stage: patch review -> resolv

[issue42242] Backport SQLite trace API v2

Erlend Egeberg Aasland added the comment: > [not sure if this is how you do backporting, a new issue and GH PR for each > supported release tag?] Backports are almost always created as backports of a specific GitHub pull request. The pull request is labelled as, for example, "needs backport

[issue42242] Backport SQLite trace API v2

Change by Erlend Egeberg Aasland : -- keywords: +patch nosy: +erlendaasland nosy_count: 1.0 -> 2.0 pull_requests: +22017 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19581 ___ Python tracker

[issue42242] Backport SQLite trace API v2

New submission from Samuel Marks : Backports https://github.com/python/cpython/pull/19581 https://bugs.python.org/issue40318 as per https://bugs.python.org/issue42229 See also 3.9 backporting: https://bugs.python.org/issue42241 [not sure if this is how you do backporting, a new issue and GH P