"Tim Peters" <tim_one@email.msn.com> writes: > [Thomas Heller] > > ... > > So is the policy now that it is no longer *allowed* to create another > > thread state, while in previous versions there wasn't any choice, > > because there existed no way to get the existing one? > > You can still create all the thread states you like; the new check is in > PyThreadState_Swap(), not in PyThreadState_New(). So you can create them, but are not allowed to use them? (Should there be a smiley here, or not, I'm not sure) > > There was always a choice, but previously Python provided no *help* in > keeping track of whether a thread already had a thread state associated with > it. That didn't stop careful apps from providing their own mechanisms to do > so. > > About policy, yes, it appears to be so now, else Mark wouldn't be raising a > fatal error <wink>. I view it as having always been the policy (from a > good-faith reading of the previous code), just a policy that was too > expensive for Python to enforce. There are many policies like that, such as > not passing goofy arguments to macros, and not letting references leak. > Python doesn't currently enforce them because it's currently too expensive > to enforce them. Over time that can change. I'm confused: what *is* the policy now? And: Has the policy *changed*, or was it simply not checked before? Since I don't know the policy, I can only guess if the fatal error is appropriate or not. If it is, there should be a 'recipe' what to do (even if it is 'use the approach outlined in PEP311'). If it is not, the error should be removed (IMO). > Clearly, I like having fatal errors for dubious things in debug builds. > Debug builds are supposed to help you debug. If the fatal error here drives > you insane, and you don't want to repair the app code, No, not at all. Thanks, Thomas
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