[Python-Dev] Exposing the Android platform existence to Python modules

Shiz hi at shiz.me
Sun Aug 3 00:49:00 CEST 2014


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Guido van Rossum wrote:
> Can you give a few examples of where you'd need to differentiate
> Android from other Linux platforms in otherwise portable code, and
> where testing for the presence or absence of the specific function
> that you'd like to call isn't possible? I know I pretty much never
> test for the difference between OSX and other UNIX variants
> (including Linux) -- the only platform distinction that regularly
> comes up in my own code is Windows vs. the rest. And even there,
> often the right thing to test for is something more specific like
> os.sep.

> What's the specific change in stdlib behavior that you're proposing
> for Android?

The most obvious change would be to subprocess.Popen(). The reason a
generic approach there won't work is also the reason I expect more
changes might be needed: the Android file system doesn't abide by any
POSIX file system standards. Its shell isn't located at /bin/sh, but at
/system/bin/sh. The only directories it provides that are POSIX-standard
are /dev and /etc, to my knowledge. You could check to see if
/system/bin/sh exists and use that first, but that would break the
preferred shell on POSIX systems that happen to have /system for some
reason or another. In short: the preferred shell on POSIX systems is
/bin/sh, but on Android it's /system/bin/sh. Simple existence checking
might break the preferred shell on either. For more specific stdlib
examples I'd have to check the test suite again.

I can see the point of a sys.platform change not necessarily being
needed, but it would nice for user code too to have a sort-of trivial
way to figure out if it's running on Android. While core CPython might
in general care far less, for user applications it's a bigger deal since
they have to draw GUIs and use system services in a way that *is*
usually very different on Android. Again, platform.linux_distribution()
seems more for display purposes than for applications to check their
core logic against.
In addition, apparently platform.linux_distribution() is getting
deprecated in 3.5 and removed in 3.6[1].

I agree that above issue should in fact be solved by the earlier-linked
to os.get_preferred_shell() approach, however.

> However, since it's a stdlib module you could easily rely on a
> private API to detect Android, so this doesn't really force the
> sys.platform issue. (Or you could propose a fix that will work for
> Kivi and SL4A as well, e.g. checking for some system file that is
> documented as unique to Android.)

After checking most of the entire Android file system, I'm not sure if
such a file exists. Sure, a lot of the Android file system hierarchy
isn't really used anywhere else, but I'm not sure a check to see if e.g.
/system exists is really enough to conclude Python is running on Android
on its own. The thing that gets closest (which is the thing my
platform.py patch checks for) is several Android-specific environment
variables being defined (ANDROID_ROOT, ANDROID_DATA,
ANDROID_PROPERTY_WORKSPACE...). Wouldn't it be better to put this in the
standard Python library and expose it somehow, though? It *is* fragile
code, it seems better if applications could 'just rely' on Python to
figure it out, since it's not a trivial check.

Kind regards,
Shiz

[1]: http://bugs.python.org/issue1322#msg207427
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQQcBAEBCgAGBQJT3WrbAAoJEICfd9ZVuxW+CSEgAMgBE12MW1H+MjScIUI19cFi
yCexTCEwu1rApjGYWSUw92Ihr9LnWn4aL7tEBqGXHN5pDctw0/FlGH9d0WhpMz/b
DN0w5ukqx2YyY1EDK7hp1//6eU+tXTGQu890CWgboj5OQF8LXFyN6ReG0ynAKFC7
gSyYGunqCIInRdnz9IRXWgQ91F/d1D3hZq9ZNffZzacA+PIA1rPdgziUuLdThl14
P2/o98DzLRa3iTrTeW+x8f7nfbfNFmO8BLJsrce0o50BlD75YsUKVeTlwjU9IuIC
gbw5Cxo8cfBN9Eg7iLkMgxkwiEVspuLVcVmoNVL4zsuavj41jlmyZFmPvRMO7OK+
NQMq5vGPub7q4lBtlk7a8gFqDJQad7fcEgsCFTIb0nvckkEi1EeLC9kyzmVEqi3C
ngiXGVfjM0qpwLKvY+pr5adsoeJSK3dVzIfEXptsvHvOhav6oxG9nCdbe3uW2ROT
hM444FSqngUabceRe395TXu2XhXcpDNcl8Ye1ADfMZdiWFYRp8/xtNVKoWZ7Ge6D
Gcx3/QiUtXP7jvykE9GI7QGB6JKCFuBY/RloDS7miteCutl7k0GLcp3+tRmtoypi
jL3lcCtUSNOMEX4Y5CqfhMcjEVccWvy98oM4Tz7qMdYv5OwASNDAzjRFh3SbRXI+
WRVqBf5aF13hy37RbkgoweXh1qn2vBO9sUUTJFp5ymlz8WisQFr+KRnt5bcjCKAe
ycVThHQaLE/j1JOSgOmbD0Xi4hcvfFvlaNEmXTL1TiWRDC0crhM9fqObHHhWlFHv
+b6AO39vVSfz1nTxTIByr6Z3GHlTFaU6iUx9oixHModEg2ej9iXb1Hq8atMHv/Z1
thP/sZ7mRRBhakQPoL9i8+5+AIEiFnw5GnW7w74N/cRalF5SB2RpzDAudv2UHMWQ
jPpVrDbDv9BAUeZKF/hl1xCpbI3xR1zhpLP6d7kH7p9fDAcS07W2hYIkX1LCyTvx
xn0XHQKEejaAZG1HwYE/0aP1Z39SJhODZx1rFjWtgE3q1akO9hfadpRiRVhozsUT
r/cXoJN3sakPbctN7B4wMXtSTrVrwqdfPCuua6mG15uTGVbkPFze/vj4yc0b+sql
LFed7BAYV0ZSeIDswrt+JyT+ZFBNZRV8zsPPZM2hNBkEqoMHshlI8QloMRbcqDnT
GnrxeiWmJXE/DkpyTbEXUPyCm95ggm+TUfUJ/yb/GhdL1yU9xCjVcxuFmAo5s0WH
k4tra8/vU21V8OzxPmK0eGH9Sl4fUg7JsmAC/Igez+utO7lJLXwfPnUSz+Ls30ao
Xd28IYMsoQ1LCltmfN/fDl3uWJi2e/kZM9v/KTkj9AncvUsDLIOV80AP+remM9E=
=Z0j+
-----END PGP SIGNATURE-----


More information about the Python-Dev mailing list