[Python-Dev] New thread death in test_bsddb3

[Thomas Heller]

"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