├── README.md └── capi_problems.rst /README.md: -------------------------------------------------------------------------------- 1 | # Problems in the Python C API 2 | 3 | This workgroup was set up following the [recent Language Summit discussions about the C API](https://pyfound.blogspot.com/2023/05/the-python-language-summit-2023-three.html). 4 | 5 | The purpose here is to identify the problems in the current C API, and to determine which of them can be fixed incrementally. 6 | Please create an issue in the repo for each problem you identify, and that particular issue can be discussed there. 7 | 8 | We should focus, for now, on enumerating the problems rather than discussing API redesign proposals. We will be able to discuss new API designs only when we have a comprehensive view of the problems we are trying to solve. 9 | 10 | However, we do not need to wait for that before we start fixing problems that can be fixed incrementally in the current C API. Issues can be marked with the "fixable" label, and within those issues it is fine to discuss pointed solutions to the specific problem covered by this issue. 11 | -------------------------------------------------------------------------------- /capi_problems.rst: -------------------------------------------------------------------------------- 1 | 2 | ====================================== 3 | An Evaluation of Python's Public C API 4 | ====================================== 5 | 6 | 7 | Abstract 8 | ======== 9 | 10 | This **informational** document describes our shared view of the public C API. 11 | The document defines: 12 | 13 | * purposes of the C API 14 | * stakeholders and their particular use cases and requirements 15 | * strengths of the C API 16 | * problems of the C API categorized into nine areas of weakness 17 | 18 | This document **does not propose solutions** to any of the identified problems. 19 | By creating a shared list of C API issues, this document will help to guide 20 | continuing discussion about change proposals and to identify evaluation criteria. 21 | 22 | Introduction 23 | ============ 24 | 25 | Python's C API was not designed for the purposes it currently fulfils. 26 | It evolved from what was initially the internal API between the C code 27 | of the interpreter and the Python language and libraries. In its first 28 | incarnation, it was exposed to make it possible to embed Python into C/C++ 29 | applications and to write extension modules in C/C++. 30 | These capabilities were instrumental to the growth of Python's ecosystem. 31 | Over the decades, the C API grew to provide different tiers of stability, 32 | conventions changed, and new usage patterns have emerged, such as bindings 33 | to languages other than C/C++. In addition, CPython is no longer the only 34 | implementation of the C API, and some of the design decisions made when 35 | it was, are difficult for alternative implementations to work with 36 | [`Issue 64 `__]. 37 | Finally, lessons were learned and mistakes in both the design and the 38 | implementation of the C API were identified. 39 | 40 | Evolving the C API is hard due to the combination of backwards 41 | compatibility constraints and its inherent complexity, both 42 | technical and social. Different types of users bring different, 43 | sometimes conflicting, requirements. The tradeoff between stability 44 | and progress is an ongoing, highly contentious topic of discussion 45 | when suggestions are made for incremental improvements. 46 | Several proposals have been put forward for improvement, redesign 47 | or replacement of the C API, each representing a deep analysis of 48 | the problems. At the 2023 Language Summit, three back-to-back 49 | sessions were devoted to different aspects of the C API. There is 50 | general agreement that a new design can remedy the problems that 51 | the C API has accumulated over the last 30 years, while at the same 52 | time updating it for use cases that it was not originally designed for. 53 | 54 | However, there was also a sense at the Language Summit that we are 55 | trying to discuss solutions without a clear common understanding 56 | of the problems that we are trying to solve. It was decided that 57 | we need to agree on the current problems with the C API, before 58 | we are able to evaluate any of the proposed solutions. We 59 | therefore created the 60 | [`capi-workgroup `__] 61 | repository on GitHub in order to collect everyone's ideas on that 62 | question. 63 | 64 | Over 60 different issues were created on that repository, each 65 | describing a problem with the C API. They were categorized and 66 | a number of recurring themes were identified. The sections below 67 | mostly correspond to these themes, and each contains a combined 68 | description of the issues raised in that category, along with 69 | links to the individual issues. In addition, we included a section 70 | that aims to identify the different stakeholders of the C API, 71 | and the particular requirements that each of them has. 72 | 73 | 74 | C API Stakeholders 75 | ================== 76 | 77 | As mentioned in the introduction, the C API was originally 78 | created as the internal interface between CPython's 79 | interpreter and the Python layer. It was later exposed as 80 | a way for third party developers to extend and embed Python 81 | programs. Over the years, new types of stakeholders emerged, 82 | with different requirements and areas of focus. This section 83 | describes this complex state of affairs in terms of the 84 | actions that different stakeholders need to perform through 85 | the C API. 86 | 87 | Universal Actions for All Stakeholders 88 | -------------------------------------- 89 | 90 | There are actions which are generic, and required by 91 | all types of API users: 92 | 93 | * Define functions and call them 94 | * Create classes and instantiate them 95 | * Create instances of builtin and user defined types 96 | and perform operations on them 97 | * Introspect objects, including types, instances, and functions. 98 | * Raise and handle exceptions 99 | * Import modules 100 | * Manage threads 101 | * Manage sub-interpreters 102 | * Handle and send signals 103 | 104 | The following sections look at the unique requirements of various stakeholders. 105 | 106 | Extension writers 107 | ----------------- 108 | 109 | Extension writers are the traditional users of the C API. Their requirements 110 | are the universal actions listed above. 111 | 112 | Authors of Embedded Python Applications 113 | --------------------------------------- 114 | 115 | Applications with an embedded Python interpreter. Examples are 116 | `Blender `__ and 117 | `OBS `__. 118 | 119 | They need to be able to: 120 | 121 | * Configure the interpreter (import paths, inittab, sys.argv, ...) 122 | * Interact with the execution model and program lifetime, including 123 | clean interpreter shutdown and restart 124 | * Represent complex data models in a way Python can use without 125 | having to create deep copies. 126 | * Provide and import frozen modules. 127 | * Run multiple independent interpreters (in particular, when embedded 128 | in a library that wants to avoid global effects). 129 | 130 | Alternative Python Implementations 131 | ---------------------------------- 132 | 133 | Alternative implementations of Python (such as 134 | `PyPy `__, 135 | `GraalPy `__, 136 | `IronPython `__, 137 | `RustPython `__, 138 | `MicroPython `__, 139 | and `Jython `__), may take 140 | very different approaches for the implementation of 141 | different subsystems. They need: 142 | 143 | * The API to be abstract and hide implementation details. 144 | * A specification of the API, ideally with a test suite 145 | that ensures compatibility. 146 | * It would be nice to have an ABI that can be shared 147 | across Python implementations. 148 | 149 | Alternative APIs 150 | ---------------- 151 | 152 | There are several projects that implement alternatives to the 153 | C API, which offer extension users advantanges over programming 154 | directly with the C API. These APIs are implemented with the 155 | C API, and in some cases by using cpython internals. 156 | Some examples are 157 | `Cython `__, 158 | `HPy `__ and 159 | `pythoncapi-compat `__. 160 | CPython's DSL for parsing function arguments, the 161 | `Argument Clinic `__, 162 | can also be seen as belonging to this category of stakeholders. 163 | 164 | Such systems need minimal building blocks for accessing CPython 165 | efficiently. They don't necessarily need an ergonomic API, because 166 | they typically generate code that is not intended to be read 167 | by humans. But they do need it to be comprehensive enough so that 168 | they don't need to access internals, while offering them stability, 169 | and without sacrificing performance. 170 | 171 | An alternative is to have a fast API tier with less error checking 172 | and lower stability guarantees. Then the developers and users of 173 | these tools can choose whether to generate code that uses the 174 | faster or the safer and more stable version of the API. 175 | 176 | Binding generators 177 | ------------------ 178 | 179 | Libraries that create bindings between Python and other object models, 180 | paradigms or languages, such as 181 | `pybind11 `__ for C++11, 182 | `PyO3 `__ for Rust, 183 | `PySide `__ for Qt, 184 | `PyGObject `__ for GTK, 185 | `Pygolo `__ for Go, 186 | `PyJNIus `__ for Java, or 187 | `SWIG `__ for C/C++. 188 | 189 | They need to: 190 | 191 | * Create custom objects (e.g. function/module objects 192 | and traceback entries) that match the behavior of equivalent 193 | Python code as closely as possible. 194 | * Dynamically create objects which are static in traditional 195 | C extensions (e.g. classes/modules), and need CPython to manage 196 | their state and lifetime. 197 | * Adapt foreign objects (strings, GC'd containers), with low overhead. 198 | * Adapt external mechanisms, execution models and guarantees to the 199 | Python way (green threads/continuations, one-writer-or-multiple-readers 200 | semantics, virtual multiple inheritance, 1-based indexing, super-long 201 | inheritance chains, goroutines, channels, ...) 202 | 203 | Strengths of the C API 204 | ====================== 205 | 206 | While the bulk of this document is devoted to problems with the 207 | C API that we would like to see fixed in any new design, it is 208 | also important to point out the strengths of the C API, and to 209 | make sure that they are preserved. 210 | 211 | As mentioned in the introduction, the C API enabled the 212 | development and growth of the Python ecosystem over the last 213 | three decades, while evolving to support use cases that it was 214 | not originally designed for. This track record in itself is 215 | indication of how effective and valuable it has been. 216 | 217 | A number of specific strengths were mentioned in the 218 | capi-workgroup discussions. Heap types were identified 219 | as much safer and easier to use than static types 220 | [`Issue 4 `__]. 221 | 222 | API functions that take a C string literal for lookups based 223 | on a Python string are very convenient 224 | [`Issue 30 `__]. 225 | 226 | The Limited API and stable ABI hide implementation details and 227 | make it easier to evolve Python 228 | [`Issue 30 `__]. 229 | 230 | C API problems 231 | ============== 232 | 233 | The remainder of this document summarizes and categorizes the problems that were reported on 234 | the [`capi-workgroup `__] repository. The issues are grouped into nine categories: 235 | 236 | - API Evolution and Maintenance 237 | - API Specification and Abstraction 238 | - Object Reference Management 239 | - Type Definition and Object Creation 240 | - Error Handling 241 | - API Tiers and Stability Guarantees 242 | - Use of the C Language 243 | - Implementation Flaws 244 | - Missing Functionality 245 | 246 | 247 | API Evolution and Maintenance 248 | ----------------------------- 249 | 250 | The difficulty of making changes in the C API is central to this report. It is 251 | implicit in many of the issues we discuss here, particularly when we need to 252 | decide whether an incremental bugfix can resolve the issue, or whether it can 253 | only be addressed as part of an API redesign 254 | [`Issue 44 `__]. The 255 | benefit of each incremental change is often viewed as too small to justify the 256 | disruption. Over time, this implies that every mistake we make in an API's 257 | design or implementation remains with us indefinitely. 258 | 259 | We can take two views on this issue. One is that this is a problem and the 260 | solution needs to be baked into any new C API we design, in the form of a 261 | process for incremental API evolution. The other possible approach is that 262 | this is not a problem to be solved, but rather a feature of any API. In this 263 | view, API evolution should not be incremental, but rather through large 264 | redesigns, each of which learns from the mistakes of the past and is not 265 | shackled by backwards compatibility requirements. A compromise approach 266 | is somewhere between these two extremes, fixing issues which are easy 267 | or important enough to tackle incrementally, and leaving others alone. 268 | 269 | The problem we have in CPython is that we don't have an agreed, official 270 | approach to API evolution. Different members of the core team are pulling in 271 | different directions and this is an ongoing source of disagreements. 272 | Any new C API needs to come with a clear decision about the model 273 | that its maintenance will follow, as well as the technical and 274 | organizational processes by which this will work. 275 | 276 | If the model does include provisions for incremental evolution of the API, 277 | it will include processes for managing the impact of the change on users 278 | [`Issue 60 `__], 279 | perhaps through introducing an external backwards compatibility module 280 | [`Issue 62 `__], 281 | or a new API tier of "blessed" functions 282 | [`Issue 55 `__]. 283 | 284 | 285 | API Specification and Abstraction 286 | --------------------------------- 287 | 288 | The C API does not have a formal specification, it is described 289 | semi-formally in the documentation and exposed through C header 290 | files. This creates a number of problems. 291 | 292 | Bindings for languages other than C/C++ must parse C code 293 | [`Issue 7 `__]. 294 | Some C language features are hard to handle in this way, because 295 | they produce compiler-dependent output (such as enums) or require 296 | a C preprocessor/compiler rather than just a parser (such as macros) 297 | [`Issue 35 `__]. 298 | 299 | Furthermore, C header files tend to expose more than what is intended 300 | to be part of the public API 301 | [`Issue 34 `__]. 302 | In particular, implementation details such as the fields of C structs 303 | can be exposed 304 | [`Issue 22 `__ 305 | and `PEP 620 `__]. 306 | This can make API evolution very difficult, in particular when it 307 | occurs in the stable ABI as in the case of ``ob_refcnt`` and ``ob_type``, 308 | which are accessed via the reference counting macros 309 | [`Issue 45 `__]. 310 | 311 | A deeper issue was identified in relation to the way that reference 312 | counting is exposed. The way that C extensions are required to 313 | manage references with calls to ``Py_INCREF`` and ``Py_DECREF`` is 314 | specific to CPython's memory model, and is hard for alternative 315 | Python implementations to emulate. 316 | [`Issue 12 `__]. 317 | 318 | Another set of problems arises from the fact that a ``PyObject*`` is 319 | exposed in the C API as an actual pointer rather than a handle. The 320 | address of an object serves as its ID and is used for comparison, 321 | and this complicates matters for alternative Python implementations 322 | that move objects during GC 323 | [`Issue 37 `__]. 324 | 325 | A separate issue is that object references are opaque to the runtime, 326 | discoverable only through calls to ``tp_traverse``/``tp_clear``, 327 | which have their own purposes. If there was a way for the runtime to 328 | know the structure of the object graph, and keep up with changes in it, 329 | this would make it possible for alternative implementations to implement 330 | different memory management schemes 331 | [`Issue 33 `__]. 332 | 333 | Object Reference Management 334 | --------------------------- 335 | 336 | There are C API functions that return borrowed references, and 337 | functions that steal references to arguments, but there isn't a 338 | naming convention that makes this obvious, so this is error prone 339 | [`Issue 8 `__ 340 | and `Issue 52 `__]. 341 | The terminology used to describe these situations in the documentation 342 | can also be improved 343 | [`Issue 11 `__]. 344 | 345 | A more radical change is necessary in the case of functions that 346 | return borrowed references (such as ``PyList_GetItem``) 347 | [`Issue 5 `__ and 348 | `Issue 21 `__] 349 | or pointers to parts of the internal structure of an object 350 | (such as ``PyBytes_AsString``) 351 | [`Issue 57 `__]. 352 | In both cases, the reference/pointer is valid for as long as the 353 | owning object is alive, but this time is hard to reason about. Such 354 | functions should not exist in the API without a mechanism that can 355 | make them safe. 356 | 357 | For containers, the API is currently missing bulk operations on the 358 | references of contained objects. This is particularly important for 359 | a stable ABI where ``INCREF`` and ``DECREF`` cannot be macros, making 360 | bulk operations expensive when implemented as a sequence of function 361 | calls 362 | [`Issue 15 `__]. 363 | 364 | Type Definition and Object Creation 365 | ----------------------------------- 366 | 367 | The C API has functions that make it possible to create incomplete 368 | or inconsistent Python objects, such as ``PyTuple_New`` and 369 | ``PyUnicode_New``. This causes problem when the object is tracked 370 | by GC or its ``tp_traverse``/``tp_clear`` functions are called. 371 | Such functions should be removed from the C API. Related functions, 372 | such as ``PyTuple_SetItem`` which is used to modify a partially 373 | initialized tuple, should also be removed (tuples are immutable 374 | once fully initialized) 375 | [`Issue 56 `__]. 376 | 377 | A few issues were identified with type definition APIs. For legacy 378 | reasons, there is often a significant amount of code duplication 379 | between ``tp_new`` and ``tp_vectorcall`` 380 | [`Issue 24 `__]. 381 | The type slot function should be called indirectly, so that their 382 | signatures can change to include context information 383 | [`Issue 13 `__]. 384 | Several aspects of the type definition and creation process are not 385 | well defined, such as which stage of the process is responsible for 386 | initializing and clearing different fields of the type object 387 | [`Issue 49 `__]. 388 | 389 | Error Handling 390 | -------------- 391 | 392 | Error handling in the C API is based on the error indicator which is stored 393 | on the thread state (in global scope). The design intention was that each 394 | API function returns a value indicating whether an error has occurred (by 395 | convention, ``-1`` or ``NULL``). When the program knows that an error 396 | occurred, it can fetch the exception object which is stored in the 397 | error indicator. A number of problems were identified which are related 398 | to error handling, pointing at APIs which are too easy to use incorrectly. 399 | 400 | There are functions that do not report all errors that occur while they 401 | execute. For example, ``PyDict_GetItem`` clears any errors that occur 402 | when it calls the key's hash function, or while performing a lookup 403 | in the dictionary 404 | [`Issue 51 `__]. 405 | 406 | Python code never executes with an in-flight exception (by definition), 407 | and by the same token C API functions should never be called with the error 408 | indicator set. This is currently not checked in most C API functions, and 409 | there are places in the interpreter where error handling code calls a C API 410 | function while an exception is set. For example, see the call to 411 | ``PyUnicode_FromString`` in the error handler of ``_PyErr_WriteUnraisableMsg`` 412 | [`Issue 2 `__]. 413 | 414 | 415 | There are functions that do not return a value, so a caller is forced to 416 | query the error indicator in order to identify whether an error has occurred. 417 | An example is ``PyBuffer_Release`` 418 | [`Issue 20 `__]. 419 | There are other functions which do have a return value, but this return value 420 | does not unambiguously indicate whether an error has occurred. For example, 421 | ``PyLong_AsLong`` returns ``-1`` in case of error, or when the value of the 422 | argument is indeed ``-1`` 423 | [`Issue 1 `__]. 424 | In both cases, the API is error prone because it is possible that the 425 | error indicator was already set before the function was called, and the 426 | error is incorrectly attributed. The fact that the error was not detected 427 | before the call is a bug in the calling code, but the behaviour of the 428 | program in this case doesn't make it easy to identify and debug the 429 | problem. 430 | 431 | There are functions that take a ``PyObject*`` argument, with special meaning 432 | when it is ``NULL``. For example, if ``PyObject_SetAttr`` receives ``NULL`` as 433 | the value to set, this means that the attribute should be cleared. This is error 434 | prone because it could be that ``NULL`` indicates an error in the construction 435 | of the value, and the program failed to check for this error. The program will 436 | misinterpret the ``NULL`` to mean something different than error 437 | [`Issue 47 `__]. 438 | 439 | 440 | API Tiers and Stability Guarantees 441 | ---------------------------------- 442 | 443 | The different API tiers provide different tradeoffs of stability vs 444 | API evolution, and sometimes performance. 445 | 446 | The stable ABI was identified as an area that needs to be looked into. At 447 | the moment it is incomplete and not widely adopted. At the same time, its 448 | existence is making it hard to make changes to some implementation 449 | details, because it exposes struct fields such as ``ob_refcnt``, 450 | ``ob_type`` and ``ob_size``. There was some discussion about whether 451 | the stable ABI is worth keeping. Arguments on both sides can be 452 | found in [`Issue 4 `__] 453 | and [`Issue 9 `__]. 454 | 455 | Alternatively, it was suggested that in order to be able to evolve 456 | the stable ABI, we need a mechanism to support multiple versions of 457 | it in the same Python binary. It was pointed out that versioning 458 | individual functions within a single ABI version is not enough 459 | because it may be necessary to evolve, together, a group of functions 460 | that interoperate with each other 461 | [`Issue 39 `__]. 462 | 463 | The limited API was introduced in 3.2 as a blessed subset of the C API 464 | which is recommended for users who would like to restrict themselves 465 | to high quality APIs which are not likely to change often. The 466 | ``Py_LIMITED_API`` flag allows users to restrict their program to older 467 | versions of the limited API, but we now need the opposite option, to 468 | exclude older versions. This would make it possible to evolve the 469 | limited API by replacing flawed elements in it 470 | [`Issue 54 `__]. 471 | More generally, in a redesign we should revisit the way that API 472 | tiers are specified and consider designing a method that will unify the 473 | way we currently select between the different tiers 474 | [`Issue 59 `__]. 475 | 476 | API elements whose names begin with an underscore are considered 477 | private, essentially an API tier with no stability guarantees. 478 | However, this was only clarified recently, in 479 | `PEP 689 `__. It is not clear 480 | what the change policy should be with respect to such API elements 481 | that predate PEP 689 482 | [`Issue 58 `__]. 483 | 484 | There are API functions which have an unsafe (but fast) version as well as 485 | a safe version which performs error checking (for example, 486 | ``PyTuple_GET_ITEM`` vs ``PyTuple_GetItem``). It may help to 487 | be able to group them into their own tiers - the "unsafe API" tier and 488 | the "safe API" tier 489 | [`Issue 61 `__]. 490 | 491 | Use of the C Language 492 | --------------------- 493 | 494 | A number of issues were raised with respect to the way that CPython 495 | uses the C language. First there is the issue of which C dialect 496 | we use, and how we test our compatibility with it 497 | [`Issue 42 `__]. 498 | 499 | Usage of ``const`` in the API is currently sparse, but it is not 500 | clear whether this is something that we should consider changing 501 | [`Issue 38 `__]. 502 | 503 | We currently use the C types ``long`` and ``int``, where ``stdint`` 504 | and ``int32_t`` would have been better choices 505 | [`Issue 27 `__]. 506 | 507 | We are using C language features which are hard for other languages 508 | to interact with 509 | [`Issue 35 `__]. 510 | 511 | There are API functions that take a ``PyObject*`` arg which must be 512 | of a more specific type (such as ``PyTuple_Size``, which fails if 513 | its arg is not a ``PyTupleObject*``). It is an open question whether this 514 | is a good pattern to have, or whether the API should expect the 515 | more specific type 516 | [`Issue 31 `__]. 517 | 518 | There are functions in the API that take concrete types, such as 519 | ``PyDict_GetItemString`` which performs a dictionary lookup for a key 520 | specified as a c string rather than ``PyObject*``. At the same time, 521 | for ``PyDict_ContainsString`` it is not considered appropriate to 522 | add a concrete type alternative. The principle around this should 523 | be documented in the guidelines 524 | [`Issue 23 `__]. 525 | 526 | Implementation Flaws 527 | -------------------- 528 | 529 | Below is a list of localized implementation flaws. Most of these can 530 | probably be fixed incrementally, if we choose to do so. They should, 531 | in any case, be avoided in any new API design. 532 | 533 | There are functions that don't follow the convention of 534 | returning ``0`` for success and ``-1`` for failure. For 535 | example, ``PyArg_ParseTuple`` returns 0 for success and 536 | non-zero for failure 537 | [`Issue 25 `__]. 538 | 539 | The macros ``Py_CLEAR`` and ``Py_SETREF`` access their arg more than 540 | once, so if the arg is an expression with side effects, they are 541 | duplicated 542 | [`Issue 3 `__]. 543 | 544 | The meaning of ``Py_SIZE`` depends on the type and is not always 545 | reliable 546 | [`Issue 10 `__]. 547 | 548 | **Naming** 549 | 550 | ``PyLong`` and ``PyUnicode`` use names which don't match the python 551 | types they represent (int/str). This can be fixed in a new API 552 | [`Issue 14 `__]. 553 | 554 | There are identifiers in the API which are lacking a ``Py``/``_Py`` 555 | prefix 556 | [`Issue 46 `__]. 557 | 558 | Some API function do not have the same behaviour as their Python 559 | equivalents. The behaviour of ``PyIter_Next`` is different from 560 | ``tp_iternext``. 561 | [`Issue 29 `__]. 562 | The behaviour of ``PySet_Contains`` is different from ``set.__contains__`` 563 | [`Issue 6 `__]. 564 | 565 | The fact that ``PyArg_ParseTupleAndKeywords`` takes a non-const 566 | char* array as argument makes it more difficult to use. 567 | [`Issue 28 `__]. 568 | 569 | Python.h does not expose the whole API. Some headers (like marshal.h) 570 | are not included from Python.h. 571 | [`Issue 43 `__]. 572 | 573 | 574 | Missing Functionality 575 | --------------------- 576 | 577 | This section consists of a list of feature requests, i.e., functionality 578 | that was identified as missing in the current C API. 579 | 580 | Debug Mode 581 | ~~~~~~~~~~ 582 | 583 | A debug mode that can be activated without recompilation and which 584 | activates various checks that can help detect various types of errors. 585 | [`Issue 36 `__]. 586 | 587 | Introspection 588 | ~~~~~~~~~~~~~ 589 | 590 | There aren't currently reliable introspection capabilities for objects 591 | defined in C in the same way as there are for Python objects. 592 | [`Issue 32 `__]. 593 | 594 | Efficient type checking for heap types, similar to what ``Py*_Check`` 595 | can do for a static type. 596 | [`Issue 17 `__]. 597 | 598 | Improved Interaction with Other Languages 599 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 600 | 601 | Interfacing with other GC based languages, and integrating their 602 | GC with Python's GC. 603 | [`Issue 19 `__]. 604 | 605 | Inject foreign stack frames to the traceback. 606 | [`Issue 18 `__]. 607 | 608 | Concrete strings that can be used in other languages 609 | [`Issue 16 `__]. 610 | 611 | References 612 | ========== 613 | 614 | 1. `Python/C API Reference Manual `__ 615 | 2. `2023 Language Summit Blog Post: Three Talks on the C API `__ 616 | 3. `capi-workgroup on GitHub `__ 617 | 4. `Irit's Discord post with Core Sprint 2023 slides about C API workgroup `__ 618 | 5. `Petr's Discord post with Core Sprint 2023 slides `__ 619 | 6. `Steve's Discord post with Core Sprint 2023 slides for Things to Learn from HPy `__ 620 | 7. `Victor's slides of Core Sprint 2023 Python C API talk: `__ 621 | 8. `The Python's stability promise — Cristián Maureira-Fredes, PySide maintainer `__ 622 | 9. `Report on the issues PySide had 5 years ago when switching to the stable ABI: `__ 623 | --------------------------------------------------------------------------------