[Martin v. L=F6wis] > There are many good reasons; here is one scenario: > > Application A calls embedded Python. It creates thread state T1 to = do > so. Python calls library L1, which releases GIL. L1 calls L2. L2 ca= lls > back into Python. To do so, it allocates a new thread state, and > acquires the GIL. All in one thread. > > L2 has no idea that A has already allocated a thread state for this > thread. With the new API, L2 does not need any longer to create a t= hread > state. However, in older Python releases, this was necessary, so > libraries do such things. I understand that some people did this (we've bumped into two so far, right?), but don't agree it was necessary: the thrust of Mark's new = code is to make this easy to do in a uniform way, but people could (and did) = build their own layers of TLS-based Python wrappers before this (Mark is on= e of them; a former employer of mine is another). AFAIK, though, these we= re cases where multiple libraries agreed to cooperate. I don't really c= are anymore, since there's a standard way to do this now. > It is unfortunate that these libraries now break, and I wish the ne= w > API would not be enforced so strictly yet. If it were enforced in a release build I'd agree, but it isn't -- a r= elease build enforces nothing new here, and I want to be punched in the groi= n when a debug build spots dubious practice. >> I already gave you my best guesses about those (no, yes). > I think your guess is wrong: In the past, it was often *necessary* = to > have multiple thread states allocated for a single thread. There wa= s > simply no other option. So it can't be that this was not allowed. It's a new world now -- let's get on with it. Fighting for the right= to retain lame code (judged by current stds, whether or not it was lame = before) isn't a cause I'll sign up for, and especially not when it's in an ex= tremely error-prone area of the C API, and certainly not when it's so easy to= repair too. But if you're determined to let slop slide in the debug build, = check in a change to stop the warning -- it's not important enough to me to= keep arguing about it. I don't think you'd be doing anyone a real favor, = and I'll leave it at that.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4