On Sat., 16 Nov. 2019, 7:29 am Eric Snow,
wrote:
> On Thu, Nov 14, 2019 at 4:12 AM Victor Stinner
> wrote:
> > Another approach would be to pass a "PyContext*" pointer which
> > contains tstate, but also additional fields. But I chose to state with
> > a direct "PyThreadState* tstate" to avoid o
As you know, I'm skeptical that PEP 554 will produce benefits that are
worth the effort, but let's assume for the moment that it is, and
we're all 100% committed to moving all globals into the threadstate.
Even given that, the motivation for this change seems a bit unclear to
me.
I guess the possi
On Tue, Nov 12, 2019 at 3:11 PM Victor Stinner wrote:
> Are you ok to modify internal C functions to pass explicitly tstate?
I'm also in favor (strongly)! (no surprises there)
The only concerns I've heard is that on some platforms there is a
measurable overhead once you hit a threshold of a spe
Victor Stinner schrieb am 12.11.19 um 23:03:
> Are you ok to modify internal C functions to pass explicitly tstate?
FWIW, I started doing the same internally in Cython a while back, because
like others, I also considered it wasteful to look it up all over the
place, often multiple times inside of
ACTIVITY SUMMARY (2019-11-08 - 2019-11-15)
Python tracker at https://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open7148 ( +8)
closed 43418 (+59)
total 50566 (+67)
Open issues wi
On Wed., 13 Nov. 2019, 8:06 am Victor Stinner, wrote:
> Hi,
>
> Are you ok to modify internal C functions to pass explicitly tstate?
>
I'll join the chorus of +1's.
With the work you've already done to clearly separate the public APIs from
the internal ones, it's now much clearer which function
