Add draft of ISOLATE_STDLIB_MODULES.rst #24
Conversation
erlend-aasland
left a comment
erlend-aasland
left a comment
There was a problem hiding this comment.
This is a very nice draft; thanks! I left some comments after reading through it once. I'll have another round later today or tomorrow.
ISOLATE_STDLIB_MODULES.rst
Outdated
| Rejected Ideas | ||
| ============== | ||
|
|
||
| Keep things as they were and not break anything |
There was a problem hiding this comment.
Would not this section make more sense in the subinterpreters or per-interpreter GIL PEPs? It feels kinda out of place here. Also, if we are to keep it, I would rephrase it to something more accurate and direct, such as "Do not isolate modules in the stdlib".
It is not clear to me what "things" is. I would guess that the sentence implies "don't convert static types to heat types", "don't convert global state to module state", "don't apply PEP 630 to the stdlib", or maybe "drop subinterpreter support". It is hard to tell. Currently, I'm afraid this will only be a source of confusion.
There was a problem hiding this comment.
Yeah, the title should have XXX as well. I guess “Do not isolate modules in the stdlib” works best, because it needs the other changes.
There was a problem hiding this comment.
We should add a short sentence about why having stdlib extension modules without multi-init support and with global state is a problem; for example, such modules would hamper a lot of Eric's work-in-progress.
Co-authored-by: Erlend Egeberg Aasland <erlend.aasland@innova.no>
ISOLATE_STDLIB_MODULES.rst
Outdated
| Do not isolate modules in the standard library | ||
| ---------------------------------------------- | ||
|
|
||
| XXX Someone write something here please |
There was a problem hiding this comment.
IMO we can reference Eric's work-in-progress (per-interpreter GIL), subinterpreters issues (multiple subinterpreters + static global state => 💥), ... anything else?
There was a problem hiding this comment.
Do we want to make this PEP depend on Eric's PEP?
IMO it would be better if it can stand on its own.
There was a problem hiding this comment.
IMO it would be better if it can stand on its own.
Yes, that's preferable.
There was a problem hiding this comment.
So, let's remove the Rejected Ideas section altogether and let the discussion generate some.
Are you happy with your name on this? I think it's ready to post to python-dev.
|
PR for the two general sections marked “XXX move this to PEP 630”: python/peps#2450 |
Co-authored-by: Erlend Egeberg Aasland <erlend.aasland@innova.no>
erlend-aasland
left a comment
erlend-aasland
left a comment
There was a problem hiding this comment.
Your #24 (comment) sounds good to me. I'm fine with putting my name on this (see one last nit); let's post it 🚀
|
Is there any issues that needs to be resolved before posting to python-dev? |
Co-authored-by: Erlend Egeberg Aasland <erlend.aasland@innova.no>
|
Just need more time in the day... |
|
PEP PR: python/peps#2499 |
2 participants
@erlend-aasland, here's a rough draft of a PEP.