[Python-Dev] Partial support of a platform (original) (raw)

Steve Dower steve.dower at python.org
Mon Nov 6 16:16:25 EST 2017

On 06Nov2017 0941, Victor Stinner wrote:

[SNIP]

But the question here is more about "partial" support. While changes are usually short, I dislike applying them to Python 2.7 and/or Python 3.6, until a platform is fully support. I prefer to first see a platform fully supported to see how much changes are required and to make sure that we get someone involved to maintain the code (handle new issues). Example of platforms: MinGW, Cygwin, OpenBSD, NetBSD, xWorks RTOS, etc.

I appreciate the desire for changes to be made upstream, especially on code that changes frequently enough to make it difficult to patch reliably (this is basically the entire premise behind my PEP 551). At the same time, I don't like carrying the burden of code for platforms we do not support (hence PEP 551 doesn't really add any interesting code). There is a balance to be found here, though.

I don't believe CPython partially supports any platforms - either they are fully supported or they are not supported.

However, we can and should do things that help other people support their platforms, such as making sure build options can be specified by environment variables. At the same time, we can and should exclude things that require platform-specific testing in core (for example, predefined options for building for a specific platform).

Similarly, if someone wanted to add specific platform support to a stdlib module via "if sys.platform ...", I'd be hesitant. However, if they refactored it such that it was easier for a custom build of CPython to provide/omit certain features (e.g. https://github.com/python/cpython/blob/30f4fa456ef626ad7a92759f492ec7a268f7af4e/Lib/threading.py#L1290-L1296 ) then I'd be more inclined to accept it - but only if there was no behavioural change on supported platforms.

Does that make sense? I'm not sure whether we ought to capture some general guidelines somewhere on how to make decisions around this, but we should certainly have the discussion here first anyway.

Cheers, Steve

More information about the Python-Dev mailing list