On Tue, Mar 3, 2015 at 9:23 AM, Wes Turner <[email protected]> wrote:
> > http://maemo.org/community/maemo-developers/identifying_platform_in_python_code/ > > Maemo sys.platform is linux2 > True - but Maemo also isn't a "supported out of the box" platform for Python, is it? Maemo might support and/or provide Python, but Python doesn't *officially* support Maemo - there's nothing in the Python tree that is maemo specific AFAICT. To me, that means that either Maemo is genuinely indistinguishable from a desktop Linux box, or they're patching Python's source tree in some way for a Maemo-specific build. It's also possible that this sys.platform identifier is an accident, rather than intention. As evidence of this - if you use the Python 2.7.2 sources that Kivy provides for Android, and you build the Python library on OS/X, sys.platform reports as "darwin". This is *clearly* wrong - but Python itself works, as long as you don't try to use anything sys-dependent. In the Maemo case, the "linux" answer could be accidental, reflecting the easiest solution they could get working, rather than a specific intention to label the platform as linux. Either way, I don't think that the decisions of someone outside the Python source tree can be cited as an absolute example for what Python itself must do. > > 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 > I'm uncertain what you're arguing here. A sys.platform.startswith check will absolutely help you pick up 'linux', 'linux2' and 'linux3' - but won't help you tell desktop Linux apart from Android. What check are you proposing a the "I'm on android" check as an alternative to sys.platform == 'android'? > Arguably, a patch for android is not yet ready if [...] > Agreed - but a patch is close (AFAICT, resolving autoconf issues is the only serious hurdle remaining), and this issue of "what does sys.platform return" is a technical issue that needs to be resolved before a patch is completed and proposed for trunk. Yours, Russ Magee %-) > 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
