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

[Guido van Rossum]

On Sat, Aug 2, 2014 at 12:14 PM, Shiz <hi at shiz.me> wrote:

> Guido van Rossum wrote:
> > sys.platform is for a broad indication of the OS kernel. It can be
> > used to distinguish Windows, Mac and Linux (and BSD, Solaris etc.).
> > Since Android is Linux it should have the same sys.platform as other
> > Linux systems ('linux2'). If you want to know whether a specific
> > syscall is there, check for the presence of the method in the os
> > module.
> >
> > The platform module is suitable for additional vendor-specific info
> > about the platform, and I'd hope that there's something there that
> > indicates Android. Again, what values does the platform module return
> > on SL4A or Kivy, which have already ported Python to Android? In
> > particular, I'd expect platform.linux_distribution() to return a
> > clue that it's Android. There should also be clues in
> > /etc/lsb-release (assuming Android supports it :-).
> >
> > -- --Guido van Rossum (python.org/~guido <http://python.org/~guido>)
>
> To the best of my knowledge, Kivy and Py4A/SL4A don't modify that code
> at all, so it just returns 'linux2'. In addition, they don't modify
> platform.py either, so platform.linux_distribution() returns empty values.
>

OK, so personally I'd leave sys.platform but improve on
platform.linux_distribution().


> My patchset[1] currently contains patches that both set sys.platform to
> 'linux-android' and modifies platform.linux_distribution() to parse and
> return a proper value for Android systems:
>
> >>> import sys, platform sys.platform
> 'linux-android'
> >>> platform.linux_distribution()
> ('Android', '4.4.2', 'Blur_Version.174.44.9.falcon_umts.EURetail.en.EU')
>
> The sys.platform thing was mainly done out of curiosity on its
> possibility after Phil bringing it up.


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.


> My main issue with leaving
> Android detection to checking platform.linux_distribution() is that it
> feels like a bit of a wonky thing for core Python modules to rely on to
> change behaviour where needed on Android (as well as introducing a
> dependency cycle between subprocess and platform right now).
>

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


> I'd also like to note that I wouldn't agree with following too many of
> Kivy/Py4A/SL4A's design decisions on this, as they seem mostly absent.
> - From what I've read, their patches mostly seem geared towards getting
> Python to run on Android, not necessarily integrating it well or fixing
> all inconsistencies. This also leads to things like subprocess.Popen()
> indeed breaking with shell=True[2].
>

I'm all for fixing subprocess.Popen(), though I'm not sure what the best
way is to determine this particular choice (why is it in the first place
that /bin/sh doesn't work?). 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.)

>
> Kind regards,
> Shiz
>
> [1]: https://github.com/rave-engine/python3-android/tree/master/src
> [2]:
>
> http://grokbase.com/t/gg/python-for-android/1343rm7q1w/py4a-subprocess-popen-oserror-errno-8-exec-format-error
>

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140802/0c95a76d/attachment.html>