René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"PEP 689 -- Add an unstable C-API tier","articleBody":"On [python-dev](https://mail.python.org/archives/list/python-dev@python.org/thread/MA4FQ7G6F35NG3TUN6RQPXRGXTYMFMDY/#MA4FQ7G6F35NG3TUN6RQPXRGXTYMFMDY), it became clear that it would be useful to have a ~~“semi-stable”~~ “unstable” C-API tier which will stay stable within a minor release.\r\n\r\n- [x] This API will go in a new directory (`Include/unstable/`) - see [Nick's reply](https://mail.python.org/archives/list/python-dev@python.org/message/CTKKTHUV5R2A2RRN5DM32UQFNC42DDGJ/)\r\nYou'll need to #define `Py_USING_UNSTABLE_API`.\r\n (name still up for bikeshedding).\r\n\r\n- [x] Since we're nearing Beta and there's no rush to break things, in 3.11 \r\nyou only get a warning if you try to use it without the opt-in #define. \r\nIn 3.12 it'll fail.\r\n\r\n- [x] The functions will be renamed to drop the leading underscore. The old \r\nnames will be available, and may be removed \r\nwhenever the API changes. (Ideally, the underscore should always mark \r\nAPI that's fully private with no guarantees at all.)\r\n\r\n- [ ] Get SC approval (this is now PEP-689 that will need acceptance)\r\n\r\n- The API will be stable during a minor release. (As usual, for extreme \r\ncases, exceptions are possible with SC approval.)\r\n\r\n- Docs:\r\n   - [x] Update https://devguide.python.org/c-api/\r\n   - [ ] Update https://docs.python.org/3.10/c-api/stable.html\r\n   - [x] Add individual reference entries for the API\r\n   - [x] Document the new opt-in macro\r\n\r\n- [ ] All ununstable API should be tested\r\n  - [x]  PEP-523 PyCode_* functions: tested in test_code\r\n  - [ ] ...\r\n\r\nWhat should be here:\r\n\r\n- [ ] Functions added in PEP-523\r\n- [x] PyCode_New, PyCode_NewWithPosOnlyArgs\r\n- [ ] Ideally anything documented as subject to change between minor \r\nreleases. (To be kind to users, if something is added later we should \r\nagain have one release of compiler warnings before requiring the opt-in. \r\nUnless that API just changed and users would get errors anyway.)\r\n- [ ] Cinder's dict writing API looks like it would feel at home here: https://github.com/python/cpython/issues/91052#issuecomment-1093945876\r\n- [ ] PyBytesObject.ob_shash sounds like a good candidate: see https://discuss.python.org/t/15108\r\n- [ ] non-opaque access to frame structs and any other key APIs needed to\r\nimplement alternate eval loops with comparable performance to the default\r\neval loop (unless \u0026 until we can figure out stable public APIs that can\r\ndeliver equivalent performance) - see [Nick's reply](https://mail.python.org/archives/list/python-dev@python.org/message/CW543RWJU6EWAPTWCDDHEUS37UHSAU5I/)\r\n- [ ] C APIs that provide access to compiled code whether in AST or opcode\r\nform (the API itself may be stable, but the compiled code isn't, so this is\r\nkinda covered by your last point) - see [Nick's reply](https://mail.python.org/archives/list/python-dev@python.org/message/CW543RWJU6EWAPTWCDDHEUS37UHSAU5I/)\r\n- [ ] `_Py_HashDouble`, see [comment below](https://github.com/python/cpython/issues/91744#issuecomment-1111105784)\r\n\r\n---\r\nFirst PR: https://github.com/python/cpython/pull/91789","author":{"url":"https://github.com/encukou","@type":"Person","name":"encukou"},"datePublished":"2022-04-20T13:50:31.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":30},"url":"https://github.com/91744/cpython/issues/91744"}