-----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----- _______________________________________________ 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
