[Python-Dev] Exposing the Android platform existence to Python modules (original) (raw)
Shiz hi at shiz.me
Sat Aug 2 14:00:04 CEST 2014
- Previous message: [Python-Dev] Exposing the Android platform existence to Python modules
- Next message: [Python-Dev] Summary of Python tracker Issues
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Akira Li wrote:
Python uses os.name, sys.platform, and various functions from
platform
module to provide version info:- coarse: os.name is 'posix', 'nt', 'ce', 'java' [1]. It is defined by availability of some builtin modules ('posix', 'nt' in particular) at import time. - finer: sys.platform may start with freebsd, linux, win, cygwin, darwin (
uname -s
). It is defined at python build time. - detailed:platform
module. It provides as much info as possible e.g., platform.uname(), platform.platform(). It may use runtime commands to get it. If Android is posixy enough (wouldposix
module work on Android?) then os.name could be left 'posix'. You could set sys.platform to 'android' (like sys.platform may be 'cygwin' on Windows) if Android is not like any other Linux distribution (from the point of view of writing a working Python code on it) i.e., if Android is further from other Linux distribution than freebsd, linux, darwin from each other then it might deserve sys.platform slot. If sys.platform is left 'linux' (like sys.platform is 'darwin' on iOS) then platform module could be used to detect Android e.g., platform.linuxdistribution() though (it might be removed in Python 3.6) it is unpredictable [2] unless you fix it on your python distribution, e.g., here's an output on my machine:import platform platform.linuxdistribution() ('Ubuntu', '14.04', 'trusty') For example: isandroid = (platform.linuxdistribution()[0] == 'Android') You could also define platform.androidversion() that can provide Android specific version details as much as you need: isandroid = bool(platform.androidversion().release) You could provide an alias androidver (like existing javaver, libcver, macver, win32ver). See also, "When to use os.name, sys.platform, or platform.system?" [3] Unrelated, TIL [4]: Android is a Linux distribution according to the Linux Foundation [1] https://docs.python.org/3.4/library/os.html#os.name [2] http://bugs.python.org/issue1322 [3] http://stackoverflow.com/questions/4553129/when-to-use-os-name-sys-platform-or-platform-system [4] http://en.wikipedia.org/wiki/Android_(operating_system) btw, does it help adding os.getshellexecutable() [5] function, to avoid hacking subprocess module, so that os.confstr('CSPATH') or os.defpath on Android could be defined to include /system/bin instead? [5] http://bugs.python.org/issue16353
Thanks for the detailed information!
I would consider Android at least POSIX-y enough for os.name to be considered 'posix'. It doesn't implement a few POSIX-mandated things like POSIX semaphores, but aside from that I would largely consider it 'compatible enough'.
I guess what is left is deciding whether to add a platform slot for Android, or to stuff the detection in platform.linux_distribution(). I feel like it would be a bit hacky for standard modules to rely on a platform.linux_distribution() return value though, it seems mostly useful for display purposes.
Phil Thompson's idea of setting sys.platform to 'linux-android' also occurred to me. Under the premise that we can get users to use sys.platform.startswith('linux'), this seems like the best solution in my eyes: it both allows for existing code to continue the assumption that they are running on a Linux platform, which I believe to be correct in a lot of places, and Python modules to use a solid value to check if they need to behave differently when running on Android.
On a sidenote, Kivy and SL4A/Py4A do not address this, no. From what I've seen from their patches they are mostly there to get Python compiling and running in the first place, not necessarily about fixing every compatibility issue. :)
As for the os.get_shell_executable(), that seems like a good solution for the issue that occurs in the subprocess module indeed. I'd personally prefer it to manual checking within the module.
Kind regards, Shiz -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQQcBAEBCgAGBQJT3NLBAAoJEICfd9ZVuxW+SnIf/jZmnxyMTcFE5IyrmOC5v53M AklKWhVK/XeK5gYAiglV7+JwIpkEHyiiIyik5QKr/ssQ/D6EjZTmb7guxoX9QZml pWHukSmEpHTJVUDtSQ9OqgRADisZKV/8Yu1pLRIqe5zDcyZLZZg7Fg01rvqpBHvp qhVzp2jdLCrcdlVZFKk3Hk04DgbJD9SUYg7ITCqj4qr5wwphCwCYfbGGlzeUXXyG /zMWB6rI86DaOcy+b8DOK4Q6xdScnwIdFaV8A3lVEBi8b8DIl5ffGe8t6WtnUBOE XGXh2wLZvnqYr31rGc0nRP16osm1usipq6jLQ4rNebzMCW/1JbybYbcOjPcOBSJw TyAjJw5KOac8hK0hapguqWKSDIYTZqnrYPy7dn8r2oXGtXGR24W/kZdELHlQi2cg HgfWf7YkA4wuMEjJQOa+ulMj34LhfmYQrj19Gy+5Pp6FA+w3r9fcKrELxXcZGZix 66WReYJOvqx78fWXdBaij7650LdOmQblrDZD4mgxiEhoiD9gDDEOib9CosyANDTf gjKatd/GOhXpJWETU6o/b1l2Yt/+cQWQbuJsvUd1jOiTn67Sf0w6Og0ZlPyV7Fgb hLp4vYWQ0rWg/UBV9H0HzPsVJz6o4wCR1+8Jj6hdgp2EFHQ0EFVCESxqiPrsFFHz CT1Ud+ZVs+2Mt7Q47Hb46RiFmzcNl6U0HZ94OczI/NpSVc/HGeY4EzyEtS18Y3Bs Sbqgst/uXJCkidcJik/YH/wIxhbngezZl0FzsWZz7BCjw99Sx4DIQJRdmHGt0CKw 3tYqus/JD+lPBGHfblMqSfCGQk4fH+1InwwKiFuxNb4nUTTC1LSqLbTYdtUk5EoG zj8RlIGG6JQaICbJZEceCDyN1sauk0Q+V3tNauMOPtgY/z/q7X15zjOtsSM15a3j TMRGUvgISq7cMT6wWgJ1o7ehizOmrJxr9E4eRb4u5CmO+bkmU/BraUULlbxRo6QB kGR21cJ0vLYip9X5Q9RS+j2P9XZClc31jLAtajeX+FZye0Hr35I7vX8RcmQT2RKu 9UqM+ow9iNr38glkDRe+QalXAknskLGbhUB4UIYI51eaHkcwmyxES9nFbcInnVbW LWtFcBErwbWass4MI/MnWlMNSqvPFa6PwZzrFS7RkpY3QqIEDK2zSdItw26EG8SG v7tqF6gdOxCs/Hc4W1DHGeuEN0e3jHgPZ+Z7KJ2l28a1zt9R853mnOElfzdFTmMM fbXCsFLFBGq3x8Vq1DIlJnE73jSDaleOI1KPWGZjbJuWO3ENaQfU+Pdf0vRwR0ot 4xPZvpSPW3n+zvddZ4g7Ly/utbeKfQWqBvDZmJnKQkA3wE6zhhKMnhnEH8D2UZs= =x/cb -----END PGP SIGNATURE-----
- Previous message: [Python-Dev] Exposing the Android platform existence to Python modules
- Next message: [Python-Dev] Summary of Python tracker Issues
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]