Message306937
| Author |
ncoghlan |
| Recipients |
docs@python, eric.snow, ncoghlan, serhiy.storchaka, vstinner |
| Date |
2017年11月25日.03:32:10 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1511580731.2.0.213398074469.issue32124@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
Key point to note regarding PEP 432: at least personally, I'm not actually aiming to deprecate the legacy embedding API.
Instead, I'm just aiming to eventually stop *adding* to it, with new config structs replacing the current ad hoc mix of pre-init function calls, C globals, environment variables, and filesystem state.
That means I'm quite willing to accept maintaining compatibility for applications using the current single phase initialisation approach as a design constraint for the PEP.
We have a similar constraint in place for extension modules:
even though any *new* features we introduce are likely to be dependent on switching over to PEP 489's multi-phase initialisation APIs, we still ensure that single-phase initialisation continues working for existing modules. |
|