On Wed., 18 Mar. 2020, 8:36 pm Mark Shannon, <m...@hotpy.org> wrote: > > > On 17/03/2020 7:00 pm, Steve Dower wrote: > > On 17Mar2020 1803, Chris Angelico wrote: > >> On Wed, Mar 18, 2020 at 3:50 AM Mark Shannon <m...@hotpy.org> wrote: > >>> The accessibility of a thread-local variable is a strict superset of > >>> that of a function-local variable. > >>> > >>> Therefore storing the thread state in a thread-local variable is at > >>> least as capable as passing thread-state as a parameter. > >>> > >> > >> And by that logic, globals are even more capable. I don't understand > >> your point. Isn't the purpose of the tstate parameters to avoid the > >> problem of being unable to have multiple tstates within the same OS > >> thread? I think I've missed something here. > > > > You haven't. Separating the Python thread from the "physical" thread is > > indeed the point. > > That seems like a strawman argument; maybe I'm misunderstanding Steve. > It seems to me that Steve is implying that using thread-local variables > somehow prevents that separation. It does not. > > The point I'm making is that adding `tstate` parameters everywhere is > unnecessary. Using a thread local variable is much less intrusive and is > at least as capable. >
And that's why the primary public API will still work that way. What the tstate work is doing is taking what are currently global functions that work on implicitly passed state and effectively turning them into C-style methods of the tstate struct. The idea is to make it so that most internal APIs won't care about the currently active thread state, they will instead operate on the tstate that they're given. In the cases where it does matter, they'll either enforce the equivalence through debug assertions or explicit checks, or else they'll take care of changing the state themselves (rather than relying on the caller to do it). The way things are now, it's like instead of defining a normal Python class instance and calling methods on it, we were instead defining a whole host of module level functions that directly manipulated passive data-only class instances stored in a thread local. The state we're trying to get to is more akin to the way Decimal context objects work: there's an active one stored in the thread local state, and functions for retrieving and changing the active context, but once you *have* a reference to a context object, you can use it directly via its methods without needing to activate it first. Cheers, Nick. >
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/JPUD4RNQDI2CIEWDIJRJ3TI5J54N6DVX/ Code of Conduct: http://python.org/psf/codeofconduct/
