Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

PEP 689 -- Add an unstable C-API tier #91744

Closed
Assignees
encukou
@encukou

Description

@encukou

Onpython-dev, 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.

  • This API will go in a new directory (Include/unstable/) - seeNick's reply
    You'll need to #definePy_USING_UNSTABLE_API.
    (name still up for bikeshedding).

  • Since we're nearing Beta and there's no rush to break things, in 3.11
    you only get a warning if you try to use it without the opt-in #define.
    In 3.12 it'll fail.

  • The functions will be renamed to drop the leading underscore. The old
    names will be available, and may be removed
    whenever the API changes. (Ideally, the underscore should always mark
    API that's fully private with no guarantees at all.)

  • Get SC approval (this is nowPEP-689 that will need acceptance)

  • The API will be stable during a minor release. (As usual, for extreme
    cases, exceptions are possible with SC approval.)

  • Docs:

  • All ununstable API should be tested

    • PEP-523 PyCode_* functions: tested in test_code
    • ...

What should be here:

  • Functions added inPEP-523
  • PyCode_New, PyCode_NewWithPosOnlyArgs
  • Ideally anything documented as subject to change between minor
    releases. (To be kind to users, if something is added later we should
    again have one release of compiler warnings before requiring the opt-in.
    Unless that API just changed and users would get errors anyway.)
  • Cinder's dict writing API looks like it would feel at home here:add support for watching writes to selected dictionaries #91052 (comment)
  • PyBytesObject.ob_shash sounds like a good candidate: seehttps://discuss.python.org/t/15108
  • non-opaque access to frame structs and any other key APIs needed to
    implement alternate eval loops with comparable performance to the default
    eval loop (unless & until we can figure out stable public APIs that can
    deliver equivalent performance) - seeNick's reply
  • C APIs that provide access to compiled code whether in AST or opcode
    form (the API itself may be stable, but the compiled code isn't, so this is
    kinda covered by your last point) - seeNick's reply
  • _Py_HashDouble, seecomment below

First PR:#91789

Metadata

Metadata

Assignees

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions


    [8]ページ先頭

    ©2009-2025 Movatter.jp