http://maemo.org/community/maemo-developers/identifying_platform_in_python_code/
Maemo sys.platform is linux2 http://lipyrary.blogspot.com/2011/09/python-and-linux-kernel-30-sysplatform.html?m=1 The correct check would be sys.platform.startswith linux If the check is for which libc, sys.platform is the wrong differentiator If the check is for PATH, sys.platform is the wrong check Arguably, a patch for android is not yet ready if [...] On Mar 2, 2015 7:14 PM, "Russell Keith-Magee" <[email protected]> wrote: > > On Sun, Mar 1, 2015 at 9:38 AM, Wes Turner <[email protected]> wrote: > >> >> >> On Sat, Feb 28, 2015 at 5:35 PM, Russell Keith-Magee < >> [email protected]> wrote: >> >>> >>> On Sat, Feb 28, 2015 at 10:07 AM, Wes Turner <[email protected]> >>> wrote: >>> >>>> >>>> >>>> On Fri, Feb 27, 2015 at 6:40 PM, Russell Keith-Magee < >>>> [email protected]> wrote: >>>> >>>>> [...] and, IMHO, a specific platform module for Android (as I've said >>>>> previously in this forum, I don't believe an Android device should >>>>> identify >>>>> as "Linux", or iOS as "Darwin", because those identifiers are misleading >>>>> on >>>>> mobile devices). >>>>> >>>>> >>>> re: sys.platform and mobile platforms >>>> >>>> iOS is not built on a Darwin kernel. Android is built on a Linux (3) >>>> kernel. >>>> >>>> For android, I think sys.platform="linux2" makes sense for things like >>>> pathlib (which, I assume, checks sys.platform) largely because *most* >>>> things should be linux-compatible (if mostly read-only and SELinux MAC >>>> controlled). Otherwise, many existing libraries would need to be >>>> unnecessarily patched. >>>> >>> >>> Sure - Android is a lot more "linux-like" than iOS is "Darwin-like"; >>> however, there are still a lot of differences. You can't assume /usr/bin is >>> populated with all the usual utilities, and that they are executable with >>> Popen, for example. >>> >> >> The existence of executables in $PATH is not a fair assumption from >> either os.name or sys.platform. >> (see: distutils.spawn.find_executable (!), sarge). >> > > Sure. My point is that if you actually have a Linux box, you can assume > you have a PATH, and you can assume the existence of /bin, /usr/bin, and > it's probably reasonable to assume the existence of a bunch of basic Unix > utilities that will behave in predictable Unix ways. That isn't a > reasonable assumption for Android. > > Plus, I only gave popen/spawn as one example; it isn't the only platform > related issue. My personal use case is widget toolkits - if you're on a > desktop Linux machine, the native widget toolkit is probably GTK+ or Qt; if > you're on Android, it's the native Java widgets. > > The core of my point - Android may use a Linux kernel, but to say Android > "is just a Linux" is a massive oversimplification. Any code that made that > assumption would almost certainly need to have a second level "if Android > else..." check anyway. > > Looking at other precedents in the source tree - there's a different > platform backend for each AIX, FreeBSD and IRIX *version*. I'll wager the > difference between FreeBSD 5 and FreeBSD 6 are much less significant than > the differences between a desktop Linux and Android. > > >> >>> IMHO, it would still be a lot more helpful to differentiate "linux2" >>> from "android" at the sys.platform level. Yes, this means existing >>> libraries etc may need to be patched. However, I don't see that as a bad >>> thing. Verifying that a package actually works on mobile, rather than just >>> assuming it will, seems like a prudent approach to me. >>> >> >> This is a hard question. Without reasonable build environments, it's very >> unlikely that anyone will have the resources to test on these other >> platforms (and architectures); so things could be arbitrarily broken when >> they would otherwise work. Arguably, this is the responsibility of >> end-developers. >> >> I think android sys.platform should read as linux2 (even for GNU/Linux >> kernel 4.0+); but have no expertise with iOS. >> > > For me, it's not about build environments; it's about the original > developer of a third-party Python app being aware of the requirements of a > mobile platform, and opting in to supporting them. > > As soon as you have functionality than needs to be platform aware, you > need to (in theory) support all possible platforms that Python supports. > Lets say I've written a library that does a sys.platform==linux2 check; > that library will fail for anyone with AIX, or HPUX, or FreeBSD, or any of > the other supported *nix platforms that exist. The developer needs to > opt-in, and say "yes, we also support AIX" (or whatever); I'd argue that > the differences between Desktop linux and Android are such that this > "opt-in" is a process that is worthwhile enforcing. > > For me, the question comes down to this: Is it reasonable to assume that a > piece of code that works on a desktop Linux will automatically work > out-of-the-box with Android? Your position appears to be that it *is* a > reasonable assumption; my experience to date has been that this isn't the > case. The fact that significant patches are needed to the stock Python > source tree in order to get it to compile for Android supports my position. > > And even if I'm wrong, and Android==Linux2 *is* a reasonable assumption - > there are still some cases where it's necessary to differentiate between > desktop Linux and Android, so some sort of "am I on Android?" check is > going to be needed. > > My argument is that given that this check is going to be needed, why > invent something new? Why not just use "sys.platform == 'android'", and > accept that third party developers using sys.platform will need to make a > small change to support this new platform, once they've established that > their code will actually run on Android - or make whatever changes are > necessary to support the differences that exist. > > Yours, > Russ Magee %-) >
_______________________________________________ Mobile-sig mailing list [email protected] https://mail.python.org/mailman/listinfo/mobile-sig
