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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
