On Sat, 23 Feb 2019 at 02:40, Victor Stinner <vstinner@redhat.com> wrote:
Currently, the whole API are based on some key features:
- PyObject object model and C structures
- CPython GC implementation
- CPython memory allocators
I'm not sure how adding more layers will help to move away from these "legacy contraints".
Don't think of it as adding more layers - think of it as clarifying the layers that already exist.
For example, there are some layers in the existing API that you can use with nary an INCREF or DECREF in your own code, because all you're doing is taking the results of language runtime API calls and passing them back to other API calls, but that isn't clear from the current API structure.
- Dynamic memory allocation/deallocation is part of the Platform adaptation layer, but there is no way to avoid it here. So any user of the core API will need to provide allocators and deallocators. The CPython Platform adaptation layer provides the "default" implementations, but if an embedder does not want to use these then targeting the Core layer will omit them.
- File system and standard streams are part of the Platform adaptation layer, which leaves
openandsys.stdout(among others) without a default implementation. An application that wants to support these without adding more layers needs to provide its own implementations- The core layer only exposes UTF-8 APIs. Encoding and decoding for the current platform requires the Platform adaptation layer, while arbitrary encoding and decoding requires the Optional stdlib layer.
- Imports in the core layer are satisfied by a "blind" callback. The Platform adaptation layer provides the support for frozen, bytecode and natively-encoded source imports, while the Optional stdlib layer is required for arbitrary encodings in source files
Oh wow, that's going a little bit too far into the complex "Python initialization API" problem. I would prefer to discuss it in a separated PEP / thread.
The two are pretty closely related, since the further down the layer stack you get, the more runtime specific the APIs involved become. Components up at the "optional stdlib component" layer would ideally be as portable as pure Python code, and not be tightly coupled to the CPython at runtime all, even when they're implemented as native extensions.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia