GeezerVison

@freakboy3742 was actually the one who convinced me to go this way – his reasoning is on the PEP's Discourse thread here.

Hum, I think this is a backwards incompatible change, which could result in downstream code breaking. While I think we should probably have a better way to identify Android platforms, I don't know exactly how I feel about this approach. I think at least we should get the input from people shipping and packaging Python on Android.

As I said in the discussion thread on PEP 738 - I'm a hard +1 on sys.platform == "android".

Yes, this is technically backwards incompatible with the current state of Android support in the CPython source tree. However, I'd counter that:

1. CPython doesn't currently have official support for Android. It has defacto support by way of "not breaking the build", one additional API entry point (sys.getandroidapilevel()), and a handful of other conditional branches in code; but it's not a Tier 3 platform. To the extent that the ecosystem supports Android currently, that support is very ad hoc, and almost entirely performed by the people tagged in this thread (or at most one degree of separation from those people). There are no Android packages on PyPI.

2. The current state of detecting Android is the source of so many headaches in the rest of the ecosystem. Yes there is code that will "just run" because Android reports as Linux - but that code is almost always so trivial that it would likely also work on iOS - it's really testing for POSIX, not Linux. Any package that does anything even remotely complicated requires patching to run on Android - at the very least in the build system, and often in user-space code as well. The fact that sys.platform reports as Linux means we need to use workarounds like this one everywhere that we do platform detection, because we can't just use a dictionary lookup. The only other platforms that cause this much headache are the ones that include the OS version in sys.platform - which is a pattern that (thankfully) appears to be slowly undergoing deprecation.

Repeating what I said in the discuss thread: Yes, technically, Android is a Linux. However, that is a distinction that isn't helpful in practice, because “Linux” isn’t just a kernel - it’s lots of other device expectations, filesystem expectations, userspace expectations, and more.

The most practical manifestation of this: If Android is indeed "a Linux", why are any patches needed to CPython at all? Shouldn't Android "just work" as a Linux, or fall out of trivial configuration checks? Unless I'm mistaken, that there are less conditional branches in the test suite for FreeBSD support than are required for Android. If that isn't an indication that Android isn't "a Linux" in practice, I don't know what is.

@erlend-aasland: I've applied your suggestions, so I think this should be ready to merge now.

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

I have made the requested changes; please review again.

I've also cleaned up the sys.platform documentation as follows:

• Removed the reference to "append platform-specific components to sys.path". This has not been true since Python 3.7 (https://bugs.python.org/issue28046).
• Added iOS as specified in PEP 730.
• Sorted the table in alphabetical order.
• Moved the table to the top, since it now contains all supported platforms [EDIT – except FreeBSD].
• Removed recommendation to use startswith on Linux and AIX. The last Python version to require this for Linux was 3.2, and the last for AIX was 3.7, both of which are now obsolete.

Thanks for making the requested changes!

@erlend-aasland, @FFY00: please review the changes made to this pull request.