PEP 788: Add some minor clarifications

[ZeroIntensity]

This doesn't change anything about the PEP, but fixes a few clarity issues that quickly came up. Sorry for the churn and extra PR here :(

---

📚 Documentation preview 📚: https://pep-previews--4391.org.readthedocs.build/pep-0788/

[ZeroIntensity]

While we're here, please let me know if there are any other unclear sections. I have a bit of expert blindness, and I'd really rather make this the only follow-up for English issues.

[AA-Turner]

I'd really rather make this the only follow-up for English issues.

There's no problem at all with more follow-ups, we'd rather have a clearer PEP than any arbitary limit on the number of edits allowed!

A

[vstinner]

In the case where it is useful to let the interpreter finalize, such as in a signal handler where there’s no guarantee that the thread will start, strong references to an interpreter can be acquired through PyInterpreterState_Lookup().

I suggest to remove mention of "signal handler". IMO a signal handler should not and cannot use the Python C API. There are too many constraints to write async-signal safe code.

[vstinner]

You may add a PyThreadState_GetDaemon() function.

[ZeroIntensity]

I have a few concerns about PyThreadState_GetDaemon. Let's do that in a different PR where I can update the rationale and specification, because we'll likely need to change how threading finalizes its threads for that to be practical.

[ZeroIntensity]

@AA-Turner @hugovk Could one of you give this a quick review? This is supposed to just add a few clarifications, not change the proposal. I'll do a big "round 1 comments" PR separately.

[CAM-Gerlach]

Not Adam or Hugo so I'm coming in blind here (though perhaps not the worst thing from the "curse of knowledge" perspective you refer to), but I gave it a quick PEP Editor review for ya. Looked good aside from a couple small clarity suggestions!