[Python-Dev] Partial support of a platform

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