Re: [Python-Dev] Exposing the Android platform existence to Python modules
On 4 Aug 2014 03:18, "Phil Thompson" wrote: > > On 03/08/2014 4:58 pm, Guido van Rossum wrote: >> >> But *are* we going to support Android officially? What's the point? Do you >> have a plan for getting Python apps to first-class status in the App Store >> (um, Google Play)? > > > I do... > > http://pyqt.sourceforge.net/Docs/pyqtdeploy/introduction.html Nice! I've only been skimming this thread, but +1 for Android mostly reading as Linux, but with an extra method in the platform module that gives more details. For those interested in mobile app development, Russell Keith-Magee also announced the release of "toga" [1] here at PyCon AU. That's a Python specific GUI library that maps directly to native widgets (rather than using theming as Kivy does). I mention it as one of the things Russell is specifically looking for is more participation from folks that know the Android side of things :) [1] http://pybee.org/toga/ Cheers, Nick. > > Phil > > ___ > 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/ncoghlan%40gmail.com ___ 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
Re: [Python-Dev] Exposing the Android platform existence to Python modules
On Sun, Aug 3, 2014 at 10:16 AM, Phil Thompson wrote: > On 03/08/2014 4:58 pm, Guido van Rossum wrote: > >> But *are* we going to support Android officially? What's the point? Do you >> have a plan for getting Python apps to first-class status in the App Store >> (um, Google Play)? >> > > I do... > > http://pyqt.sourceforge.net/Docs/pyqtdeploy/introduction.html > > Phil > Oooh, that's pretty cool! -- --Guido van Rossum (python.org/~guido) ___ 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
Re: [Python-Dev] Exposing the Android platform existence to Python modules
On 03/08/2014 4:58 pm, Guido van Rossum wrote: But *are* we going to support Android officially? What's the point? Do you have a plan for getting Python apps to first-class status in the App Store (um, Google Play)? I do... http://pyqt.sourceforge.net/Docs/pyqtdeploy/introduction.html Phil ___ 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
Re: [Python-Dev] Exposing the Android platform existence to Python modules
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Guido van Rossum wrote: > But *are* we going to support Android officially? What's the point? > Do you have a plan for getting Python apps to first-class status in > the App Store (um, Google Play)? > > Regardless, I recommend that you add a new method to the platform > module (careful people can test for the presence of the new method > before calling it) and leave poor sys.platform alone. Well, that is the idea, at least empowering people to write proper Android apps in Python. The first step of that would be making CPython run on Android, the second step would be adding libraries that allow Python users to interface with the Android API. As I said, even if the CPython maintainers are not willing to support Android in the end, I'd at least like my patchset to be done according to CPython development guidelines/principles as close as possible. Adding android_version() to the platform module it is, then. hasattr(platform, 'android_version') is probably an easy enough check for Python users. Kind regards, Shiz -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQQcBAEBCgAGBQJT3l2hAAoJEICfd9ZVuxW+01AgALmVjV30qJ7HEOJEslb7sET4 9wPd1n3BLp/cmGxxLynMmQ6PDv5pHwjJT/QqwpW6xbYCnJ/5M5/8jMOXjMgedJ0C +wSx4/Detv0Cp5fXIFy3G8fS6yIm30mRrVzAq6gJ0I+NqkzR8S/DeIsonz/vJmEI aWxVra4jd7zPmAV/mUr0nwJ1xyEHWJnW+CPsc1FRI+YKgMbJnegFo+7GrthkuJen jmbrAQbt6FG0tKBGgmfL6r6r+c+5KSQYH+VLESpcIJGZbNr7IVpGhRB247njVLug AsqXFvabGU0/RHmJnLa0a09AH2NZYkhMqv9Ncaamf2DijVMN9Wez4UFpPTUkxNlJ qfK0S6vafDW0FKNNe07xn1fQi3Lrax1pZlX7emGp9TplsctPTNVEfnQfcgJpXlrj rATtH3MVxD7nf8WjYwGXcFpECxNdy1+096neqp9jkWkXpQZhr1qtUiXe6Ez4DUxe 4H1ZWOmuu+HJHVMN3wDjr5VUMcdzjUMA2DgHIkstfNqkEb3U4//5UFro5/plmGkc qvcU5SQMPKCff+LB2dvgpmYNVZDuj8AHb1t805KesW+eEmcIEgQ4zn+pcBr/+B13 8yal38Ms8jl9flqVcLFlqpAQyIcLdjtdMsyG3DUvZ26ChRF2NSITMYL6hn12VbEK UiXK8uus2YE0SRfJ1mJthg8vk+DOqGxsaT4XdvfoFykQo2W1JYKlS69Fnxsnl8MN 6KPNOmscQAfLfGKBiIjDqlcNFnKcAUJE5paywrNQkb3Kq+5NZqK3swNieOvaSI9b e23cP0GmCJUW0vlRJzjhpSpAMR4hy6TF8wEJavAb4s7IgQi928mVEVEFhVLDIXNi kZFG2BXQZ9aAc1pwBxFaeuGHvIAiJ+lYB6E6bg2LIEtDBeBSf8JMk1+FtIOaLD6L W/J0c2PHpSX11mPlmQBmQwbhSJ9s3lQE4bYVh7MQf/dPWLYFCO+8fXlRykZK10cj advO51WyrYldecSiAufyPShP0ouU6Qw7wrDByBxD7BmsCqwmblx8yNJz8pwvD33q hYVl3LWtf1KJIpC44Kcob06z2bi/r91nbIQgFm01LiIrwuPoa9ydrwl3ET+qrjle +FYXR0NEk3RmjNoo+MaXXfxrz4lUcFv+olGf6A/dVvsd8XpxibTaxBcpppTl6o9M oLYFw1c2f5psmrVByXpiEWuvjnSvcSnjEV7qlGI2dSGks1aq/R6otNenwr/BgamO OkvA9DmBKvfJ5MdATjYtVLSBj5om1yqQnGm1snqkDDnWIQx60i5LXeNvJE6XyD1s MM0d4WVZqNwZsrOa5/Yd2rHi1L+14aFctk40IocVUFOUrMVX52oKGyKovylRqNk= =N1mB -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
Re: [Python-Dev] Exposing the Android platform existence to Python modules
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Akira Li wrote:
> FYI, /bin/sh is not POSIX, see
> http://bugs.python.org/issue16353#msg224514
Ah right, my apologies. Android doesn't seem to have getconf(1) either,
but sh /is/ on $PATH. Anyway, even if it weren't, os.defpath could be
tweaked on Android.
> I don't see sysconfig mentioned in the discussion (maybe for a
> reason). It might provide build-time information e.g.,
>
> built_for_android = 'android' in
> sysconfig.get_config_var('MULTIARCH')
>
> assuming the complete value is something like 'arm-linux-android'.
> It says that the python binary is built for android (the current
> platform may or may not be Android).
MULTIARCH is empty in my sysconfig (http://txt.shiz.me/MjBmOTQ4). You
could possibly match HOST_GNU_TYPE against 'androideabi', even though it
still seems a bit fragile. Please ignore MACHDEP/PLATDIR, those are set
as a result of me fiddling with sys.platform.
Kind regards,
Shiz
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQQcBAEBCgAGBQJT3lyaAAoJEICfd9ZVuxW+8D4gAL8Bi7gvHQlaDOPDWjILeFEy
DN7t4RGuVBGv2MYhMJPgHQy27bUAQLXtEWNYFGl8X9mK3BdDlrDfmcVxnN4hJPJD
iqWHlECN/yY4+fkzLbq85OHKyWKo410SHssyCd2X4WeGJL6PVcnq50/bYhsDd8gf
31ICjfDCs8ZFFSIxdb0KzLE7dXOIBnsB4QLFqi6KUwiJYls6JyOhfwYt1UU5/7he
J0urNh/cJomHCrod26A/C9sBGB6LcjIv5xIYosQ0C7dpYfRyfF+JRuzHcA2Wm6NY
gt1jAeRHSb+YihbuTwtsH6gPopXWdSY1IWtBX+Q98Je95weO12dI1M1BRCRk7yW1
AyRyclnBjFAKkYAzuCEIQxFBpmKYkO4W23CBjUvK21AmpV86sK1A6OWRPPADAthw
jQpXsfv2WFIEpZsVFZ2YQ1hTcdCnUdAoCaJbFkH8hhFXRF3A9asO1N0ff0sEFNe2
kRSJD8wzgMjy98c3xAmwfXCRCbM7kIkM87R2Mw+cIWC1/xV3erlOmCtKkVbAUJSK
3r+w33meFmYGQGrh3TaCScBIN6aoYTIQKJOGwWKYp8fa313qW8BQjSw7WzOLCjNM
8zDFuBfQJvVCs/eiMcFTMHaHBaXj9rNNw7pyQBwMXUQUWntIP/Pio6sZJEjJ4tM7
SIHtqfGT+kHN8PIPj/1PM9VuXge4Z97d2TXplwAfmNc2D/mvnfu0bswBVFuRzNi7
9a4P8jIrw5ZqMF/tKE7ykk79Xz3hwCEm+W8rzzqiz5P8Wn39YTXd5dX/EXaoOzmh
vWAF7opI7vHeA0f8rfkgkvBBhy6g74ku1Ie2k9KzrcMlKUMYEH60QWzcj1POT6oz
ovfciahZtAN11j0+M3GIKWnuLXTieoPOaYa4EuPe+ZFqTg1pAAX0z2saKNAXR7Fo
hITS1WeN3kenXmkAzWTkX+2tb+TtbKOhd5MURWMbUIaTFjzYvgFAtpyTHZExWO6a
zpWYcWBGFn4c16rgK8VD/UYIqA7xIwmhtkz0UBXtIM2za8AidR8nZph0cgpH0EnC
IwzjAy5WT2WxUGBHcRwA+FhPQYxZPcai/QAAs2VPLm3srmGvYwmLibqS0FUL+tME
xl5p/2NkwDuP3Q8TBvIMXmxTk5X0w7c8/cSGMYcujkK6dsodhrdmw2IwNf/pQ8tW
FUuY0znvfKfklqN6BfeN7tLF9rDlaHlOE0iRM24Qx1mFvKA9RXrhXok1BBO0WYK4
jklFC4WdYhqEw47GsXDkO8UmgvV3knoSX77g4Xq043hnbd8brydkEgd8OfqjX/JQ
4gKyYyW7yZAxrChxBg2DDyMmjMU89yLLpiI55yAdN+lT3N7aCj6DJWADNz20TvQ=
=TMlH
-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
Re: [Python-Dev] Exposing the Android platform existence to Python modules
But *are* we going to support Android officially? What's the point? Do you have a plan for getting Python apps to first-class status in the App Store (um, Google Play)? Regardless, I recommend that you add a new method to the platform module (careful people can test for the presence of the new method before calling it) and leave poor sys.platform alone. On Sat, Aug 2, 2014 at 10:18 PM, Shiz wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Guido van Rossum wrote: > > Well, it really does look like checking for the presence of those > > ANDROID_* environment variables it the best way to recognize the > > Android platform. Anyone can do that without waiting for a ruling on > > whether Android is Linux or not (which would be necessary because the > > docs for sys.platform are quite clear about its value on Linux > > systems). Googling terms like "is Android Linux" suggests that there > > is considerable controversy about the issue, so I suggest you don't > > wait. :-) > > Right, which brings us back to the original point I was trying to make: > any chance we could move logic like that into a sys.getandroidversion() > or platform.android_version() so user code (and standard library code > alike) doesn't have to perform those relatively nasty checks themselves? > It seems like a fair thing to do if CPython would support Android as an > official target. > > Kind regards, > Shiz > -BEGIN PGP SIGNATURE- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQQcBAEBCgAGBQJT3cYHAAoJEICfd9ZVuxW+hSogAKg8FUz/SuH6d0a4QvDctpMO > pm58gBqVYvd1y/uIiLpQgpGb1dPrNziV1IYOBJaDcU1i/03JlgGdr3HOq29KvHdQ > xgaQQbsyl63Tzhs4oA2iow7eoRO5rkZ338hxpWrUQqRek73AYXJt2r5w9dRklUh/ > Z1R+80otVRAj69uJub8yAys08QqljKG80cnfQwUcFJVDWZRmr/z/WRGoC7QkRYVK > EfIa7EVlm/3mArmueF6vxgF5qHevXIHvVSf18JJ918gxldKLJ4ht1v8L/4h4QBrC > zfNqWyg8lXh6evMMH4lM755rycCTrtyzkoxmocLkUsEHrB65eOWWSBYdQgRMpuOH > SZs+9K+P1jPwsJlcHl8j4sXoG6NtL6BBim70nlEnvdWQ6qHMivBNcyA1gEwI7Upn > hG4t7AM4c3fdbkOg4V1F7EVrS9QqIxxWFIMAfYUGstZnfbBUDDGKIkE68ZbT+scq > RTLbh78WsVA/YB/NLnxKvCTCuJb2uwg7R/VC1bMlsTUqTSfmckHl/XSRrgk+ggve > A45sOKyoWzpfZEaAL9/e2TsPul5bRatVFX2JqEuzO42OTNZRr7GRxvRgF4tmnmG2 > baSfrEhm3rcIFxT2IqLy+28g7ffGKcbbq7oo7LPvrh+zIupamygCnvMs6aSPE3zi > Vi31EiFrZ8pn3YF+yfO7D9hjtqE41IIc86dKPUyKYfG+wO1oPXNwzBEZfoRSoJaY > 9EKd1fqOm9iYHHzr+mkEko/bl+SxNFHHJ/y/uEU6ZIhBjbylDJ9AKCAm5q9gotuT > 5i3PuyOOrTuYO0ei0su5Ya9UO5vD3+gUNKTHe9IdUL/e+5qYt5tjwtfPC9UTldSy > xLv8Ca0uC7mOHLPi8ASghoO2tbjy69TNYmzljqIGUufBOKshFnNWA7DDmQdYrdTN > t+EXsUAUmqm1RT29Zhrt1LCsoByyXh5jBapyIleU8TTrmotpX3dlI7rooZSegUiy > 8lD05oIjX+JRbfXXsNg384e6Stc6UktrhIK00w3ILVP9IqnqAO+dao/uE+5lLvxU > BcL9/PjmTY+1U8ZJCb9uZXNG8jWP2lsQEKaSFURkoUjTzfRpAoa6tVpCZOOvqZC2 > F52ZSwmUBtP7vydRJ7BZjOeRxDzMD8qd0ED3fciDRbnVdXHIG+8MFL5MY1CDm9i7 > r7bngcsqSUURq/Zj4BYnM8lOX1PXC9+U4gVNEkiwf+9CjfeIyMd4QpuMyXPxeiUa > QDU8MX5VdA1oBvJ2nbXV8QwriIfODbyhD/00QhLHw5ifKjxB8ZZdF4jNT+Ay9jnR > nEWuIpat3ch2Sg/ECtBvcA8hHYE9TfFZGdrdZVvib7fHsS+AUFXuhjAnkEyOVB4= > =m+JD > -END PGP SIGNATURE- > -- --Guido van Rossum (python.org/~guido) ___ 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
Re: [Python-Dev] Exposing the Android platform existence to Python modules
Shiz writes: > 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. FYI, /bin/sh is not POSIX, see http://bugs.python.org/issue16353#msg224514 -- Akira ___ 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
Re: [Python-Dev] Exposing the Android platform existence to Python modules
Guido van Rossum writes:
> Well, it really does look like checking for the presence of those ANDROID_*
> environment variables it the best way to recognize the Android platform.
> Anyone can do that without waiting for a ruling on whether Android is Linux
> or not (which would be necessary because the docs for sys.platform are
> quite clear about its value on Linux systems). Googling terms like "is
> Android Linux" suggests that there is considerable controversy about the
> issue, so I suggest you don't wait. :-)
I don't see sysconfig mentioned in the discussion (maybe for a
reason). It might provide build-time information e.g.,
built_for_android = 'android' in sysconfig.get_config_var('MULTIARCH')
assuming the complete value is something like 'arm-linux-android'. It
says that the python binary is built for android (the current platform
may or may not be Android).
--
Akira
___
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
Re: [Python-Dev] Exposing the Android platform existence to Python modules
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Guido van Rossum wrote: > Well, it really does look like checking for the presence of those > ANDROID_* environment variables it the best way to recognize the > Android platform. Anyone can do that without waiting for a ruling on > whether Android is Linux or not (which would be necessary because the > docs for sys.platform are quite clear about its value on Linux > systems). Googling terms like "is Android Linux" suggests that there > is considerable controversy about the issue, so I suggest you don't > wait. :-) Right, which brings us back to the original point I was trying to make: any chance we could move logic like that into a sys.getandroidversion() or platform.android_version() so user code (and standard library code alike) doesn't have to perform those relatively nasty checks themselves? It seems like a fair thing to do if CPython would support Android as an official target. Kind regards, Shiz -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQQcBAEBCgAGBQJT3cYHAAoJEICfd9ZVuxW+hSogAKg8FUz/SuH6d0a4QvDctpMO pm58gBqVYvd1y/uIiLpQgpGb1dPrNziV1IYOBJaDcU1i/03JlgGdr3HOq29KvHdQ xgaQQbsyl63Tzhs4oA2iow7eoRO5rkZ338hxpWrUQqRek73AYXJt2r5w9dRklUh/ Z1R+80otVRAj69uJub8yAys08QqljKG80cnfQwUcFJVDWZRmr/z/WRGoC7QkRYVK EfIa7EVlm/3mArmueF6vxgF5qHevXIHvVSf18JJ918gxldKLJ4ht1v8L/4h4QBrC zfNqWyg8lXh6evMMH4lM755rycCTrtyzkoxmocLkUsEHrB65eOWWSBYdQgRMpuOH SZs+9K+P1jPwsJlcHl8j4sXoG6NtL6BBim70nlEnvdWQ6qHMivBNcyA1gEwI7Upn hG4t7AM4c3fdbkOg4V1F7EVrS9QqIxxWFIMAfYUGstZnfbBUDDGKIkE68ZbT+scq RTLbh78WsVA/YB/NLnxKvCTCuJb2uwg7R/VC1bMlsTUqTSfmckHl/XSRrgk+ggve A45sOKyoWzpfZEaAL9/e2TsPul5bRatVFX2JqEuzO42OTNZRr7GRxvRgF4tmnmG2 baSfrEhm3rcIFxT2IqLy+28g7ffGKcbbq7oo7LPvrh+zIupamygCnvMs6aSPE3zi Vi31EiFrZ8pn3YF+yfO7D9hjtqE41IIc86dKPUyKYfG+wO1oPXNwzBEZfoRSoJaY 9EKd1fqOm9iYHHzr+mkEko/bl+SxNFHHJ/y/uEU6ZIhBjbylDJ9AKCAm5q9gotuT 5i3PuyOOrTuYO0ei0su5Ya9UO5vD3+gUNKTHe9IdUL/e+5qYt5tjwtfPC9UTldSy xLv8Ca0uC7mOHLPi8ASghoO2tbjy69TNYmzljqIGUufBOKshFnNWA7DDmQdYrdTN t+EXsUAUmqm1RT29Zhrt1LCsoByyXh5jBapyIleU8TTrmotpX3dlI7rooZSegUiy 8lD05oIjX+JRbfXXsNg384e6Stc6UktrhIK00w3ILVP9IqnqAO+dao/uE+5lLvxU BcL9/PjmTY+1U8ZJCb9uZXNG8jWP2lsQEKaSFURkoUjTzfRpAoa6tVpCZOOvqZC2 F52ZSwmUBtP7vydRJ7BZjOeRxDzMD8qd0ED3fciDRbnVdXHIG+8MFL5MY1CDm9i7 r7bngcsqSUURq/Zj4BYnM8lOX1PXC9+U4gVNEkiwf+9CjfeIyMd4QpuMyXPxeiUa QDU8MX5VdA1oBvJ2nbXV8QwriIfODbyhD/00QhLHw5ifKjxB8ZZdF4jNT+Ay9jnR nEWuIpat3ch2Sg/ECtBvcA8hHYE9TfFZGdrdZVvib7fHsS+AUFXuhjAnkEyOVB4= =m+JD -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
Re: [Python-Dev] Exposing the Android platform existence to Python modules
Well, it really does look like checking for the presence of those ANDROID_* environment variables it the best way to recognize the Android platform. Anyone can do that without waiting for a ruling on whether Android is Linux or not (which would be necessary because the docs for sys.platform are quite clear about its value on Linux systems). Googling terms like "is Android Linux" suggests that there is considerable controversy about the issue, so I suggest you don't wait. :-) On Sat, Aug 2, 2014 at 3:49 PM, Shiz wrote: > -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/j1JOSgOmbD0Xi4hcvfFvlaNEmXTL1Ti
Re: [Python-Dev] Exposing the Android platform existence to Python modules
Shiz wrote: 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. Since MacOSX has /System and typically a case-insensitive file system, it certainly wouldn't. :-) -- Greg ___ 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
Re: [Python-Dev] Exposing the Android platform existence to Python modules
-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- __
Re: [Python-Dev] Exposing the Android platform existence to Python modules
On Sat, Aug 2, 2014 at 12:14 PM, Shiz 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 )
>
> 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)
___
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
Re: [Python-Dev] Exposing the Android platform existence to Python modules
Right.
On Saturday, August 2, 2014, Phil Thompson
wrote:
> On 02/08/2014 7:36 pm, Guido van Rossum wrote:
>
>> On Sat, Aug 2, 2014 at 12:53 AM, Phil Thompson <
>> p...@riverbankcomputing.com>
>> wrote:
>>
>> To me the issue is whether, for a particular value of sys.platform, the
>>> programmer can expect a particular Python stdlib API. If so then Android
>>> needs a different value for sys.platform.
>>>
>>>
>> 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.
>>
>
> It's not just the os module - other modules contain code that would be
> affected, but there are plenty of other parts of the Python stdlib that
> aren't implemented on every platform. Using the approach you prefer then
> all that's needed is to update the documentation to say that certain things
> are not implemented on Android.
>
> Phil
>
--
--Guido van Rossum (on iPad)
___
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
Re: [Python-Dev] Exposing the Android platform existence to Python modules
On 02/08/2014 7:36 pm, Guido van Rossum wrote:
On Sat, Aug 2, 2014 at 12:53 AM, Phil Thompson
wrote:
To me the issue is whether, for a particular value of sys.platform,
the
programmer can expect a particular Python stdlib API. If so then
Android
needs a different value for sys.platform.
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.
It's not just the os module - other modules contain code that would be
affected, but there are plenty of other parts of the Python stdlib that
aren't implemented on every platform. Using the approach you prefer then
all that's needed is to update the documentation to say that certain
things are not implemented on Android.
Phil
___
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
Re: [Python-Dev] Exposing the Android platform existence to Python modules
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
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 )
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.
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. 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).
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].
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
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQQcBAEBCgAGBQJT3TiVAAoJEICfd9ZVuxW+XvAf+waDYEyURnBa7kSanThoV28b
ilx6g4rMwXBZ+R3t4a0D7Q489uSQ63IJ8KWUI6AOE3v998pUOxg4LNdhBIbnr+WD
bT5WUk/elfhhdEEM7pAVIg/r76lIgysVwW0uibZw9bS32TayUjigtxI9nEWUAH8D
48maBBX9CCy5G0aysx4zLqGr49MeRM7stRuS3yf55RArRdoUUibUyHhA7q7ACWbH
LCiV9oECmgUCvc+uzj1dZSLJR4cYsldV9GUnvgE0mSbUGfp4QlqKa9V9WrziH26e
UQ/G3nM0XmZNbdHlKfwl12x6zLq+TLADyCZV8BZEcHF6+FqmvpNyMf6Hwg3DkojX
a7UmEPcbiHcnH0ncqNB6gVu92O+qMtfaWV0kfHGIwWriNPuGfJWWiwEP/Q4TICGm
Yfo+nJ780opdUobvU9NTUjSlQoUBYlQQmJgCrUsOZTBWxZeIdyn4LpspUM7PyVaY
vXMAq+D9fYyF6LjVSv+IBU9rZnwVIxS7XFnTKt4Q/YL2upM4q9KGe5WZH4EqPjaK
1kLX1QHWlDHkCY8BdjhGHdvQBm1YhpJCRcFJgCIMzWUnWiMl4vhHYF4mp/WseiiX
DHKSiHPNd51yhMXBplksPn9gOYfaHnIKJeBccegRsmKdTfiLiyksmWSeSBuFzb8w
lHCir/u8AuadinYYS5V9bb80T6LyJKVZ74qa7dOi9Y9h1Li7ytRC8ZfkLpqUTwS/
2KOpUxNLRkyLVqCvSaGM72LIvAX7t/H0f4U9rnGRAwYJaoSjfyL6eNK8DOGo+J0a
TmueQBSnrFVI85rvCdQtSiPFAj0/UhSat5XP/3AN0X8lcnxWJFnPkYCbFMhkR3pw
Wuhvjv5Xm0gB95zcjNoKlBoISl9R6ZCLnR6td3NYZGbWxyEK4zdA7X6wGRXDK6ZX
YC5jUm6kG+lJ6WzF9SSRCtJ9IvuhFdUPu+1LuWSBrWhRT5pGJIIYr83hTLb6t6V7
zv+pHMfqYGP3IkoXYsCq+STkKmyD4Jce9uwdzHn8IncMM8KNqpwJeMlC8Wz16EsS
/jFi6wftdpCVjiXDHPGxGyuxDW+bDhLfb4giOc9Gx9Wabi3IqGjqHfDfXC1MQY+K
M9T3izX7Zvbf2g2+oxh9qftX4rGMsNe1uuS9b8Ym8Eupwv4NyHUbZx2e1glHTDJ0
u5Vt/DZqWHZPaoNT100vqfWKXlZC+BeFY+MB0k5ozBlhhdMMkST3ZVw8tve2WJCO
fwb7hbhCJ3X7J9hBzq1giljgPJuWbUadYnVa8RulLDSlXQw/yh/8jkPShTc47row
oZfxalB/0qwC+I8kWxb2Ln5LbAxqNhkahALPLSVQ/Mx/+6/shoVNQJTGc1FXn20=
=nA+h
-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
Re: [Python-Dev] Exposing the Android platform existence to Python modules
On Sat, Aug 2, 2014 at 12:53 AM, Phil Thompson
wrote:
> To me the issue is whether, for a particular value of sys.platform, the
> programmer can expect a particular Python stdlib API. If so then Android
> needs a different value for sys.platform.
>
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)
___
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
Re: [Python-Dev] Exposing the Android platform existence to Python modules
-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 (would `posix` 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.linux_distribution() 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.linux_distribution()
> ('Ubuntu', '14.04', 'trusty')
>
> For example:
>
> is_android = (platform.linux_distribution()[0] == 'Android')
>
> You could also define platform.android_version() that can provide
> Android specific version details as much as you need:
>
> is_android = bool(platform.android_version().release)
>
> You could provide an alias android_ver (like existing java_ver,
> libc_ver, mac_ver, win32_ver).
>
> 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.get_shell_executable() [5] function, to
> avoid hacking subprocess module, so that os.confstr('CS_PATH') 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/HGeY4EzyEtS
Re: [Python-Dev] Exposing the Android platform existence to Python modules
On 02/08/2014 4:34 am, Guido van Rossum wrote:
Or SL4A? (https://github.com/damonkohler/sl4a)
On Fri, Aug 1, 2014 at 8:06 PM, Steven D'Aprano
wrote:
On Sat, Aug 02, 2014 at 05:53:45AM +0400, Akira Li wrote:
> Python uses os.name, sys.platform, and various functions from `platform`
> module to provide version info:
[...]
> If Android is posixy enough (would `posix` module work on Android?)
> then os.name could be left 'posix'.
Does anyone know what kivy does when running under Android?
I don't think either do anything.
As the OP said, porting Python to Android is mainly about dealing with a
C stdlib that is limited in places. Therefore there might be the odd
missing function or attribute in the Python stdlib - just the same as
can happen with other platforms.
To me the issue is whether, for a particular value of sys.platform, the
programmer can expect a particular Python stdlib API. If so then Android
needs a different value for sys.platform.
On the other hand if the programmer should not expect to make such an
assumption, and should instead allow for the absence of certain
functions (but which ones?), then the existing value of 'linux' should
be fine.
Another option I don't think I've seen suggested, given the recommended
way of testing for Linux is to use sys.platform.startswith('linux'), is
to use a value of 'linux-android'.
Phil
___
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
Re: [Python-Dev] Exposing the Android platform existence to Python modules
Or SL4A? (https://github.com/damonkohler/sl4a) On Fri, Aug 1, 2014 at 8:06 PM, Steven D'Aprano wrote: > On Sat, Aug 02, 2014 at 05:53:45AM +0400, Akira Li wrote: > > > Python uses os.name, sys.platform, and various functions from `platform` > > module to provide version info: > [...] > > If Android is posixy enough (would `posix` module work on Android?) > > then os.name could be left 'posix'. > > Does anyone know what kivy does when running under Android? > > > -- > Steven > > ___ > 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/guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ 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
Re: [Python-Dev] Exposing the Android platform existence to Python modules
On Sat, Aug 02, 2014 at 05:53:45AM +0400, Akira Li wrote: > Python uses os.name, sys.platform, and various functions from `platform` > module to provide version info: [...] > If Android is posixy enough (would `posix` module work on Android?) > then os.name could be left 'posix'. Does anyone know what kivy does when running under Android? -- Steven ___ 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
Re: [Python-Dev] Exposing the Android platform existence to Python modules
Shiz writes:
> Hi folks,
>
> I’m working on porting CPython to the Android platform, and while
> making decent progress, I’m currently stuck at a higher-level issue
> than adding #ifdefs for __ANDROID__ to C extension modules.
>
> The idea is, not only CPython extension modules have some assumptions
> that don’t seem to fit Android’s mold, some default Python-written
> modules do as well. However, whereas CPython extensions can trivially
> check if we’re building for Android by checking the __ANDROID__
> compiler macro, Python modules can do no such check, and are left
> wondering how to figure out if the platform they are currently running
> on is an Android one. To my knowledge there is no reliable way to
> detect if one is using Android as a vehicle for their journey using
> any other way.
>
> Now, the main question is: what would be the best way to ‘expose’ the
> indication that Android is being ran on to Python-living modules? My
> own thought was to add sys.getlinuxuserland(), or
> platform.linux_userland(), in similar vein to sys.getwindowsversion()
> and platform.linux_distribution(), which could return information
> about the userland of running CPython instance, instead of knowing
> merely the kernel and the distribution.
>
> This way, code could trivially check if it ran on the GNU(+associates)
> userland, or under a BSD-ish userland, or Android… and adjust its
> behaviour accordingly.
>
> I would be delighted to hear comments on this proposal, or better yet,
> alternative solutions. :)
>
> Kind regards,
> Shiz
>
> P.S.: I am well aware that Android might as well never be officially
> supported in CPython. In that case, consider this a thought experiment
> of how it /would/ be handled. :)
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 (would `posix` 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.linux_distribution() 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.linux_distribution()
('Ubuntu', '14.04', 'trusty')
For example:
is_android = (platform.linux_distribution()[0] == 'Android')
You could also define platform.android_version() that can provide Android
specific version details as much as you need:
is_android = bool(platform.android_version().release)
You could provide an alias android_ver (like existing java_ver, libc_ver,
mac_ver, win32_ver).
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.get_shell_executable() [5] function, to
avoid hacking subprocess module, so that os.confstr('CS_PATH') or
os.defpath on Android could be defined to include /system/bin instead?
[5] http://bugs.python.org/issue16353
--
Akira
___
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
Re: [Python-Dev] Exposing the Android platform existence to Python modules
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Charles-François Natali wrote: > Well, Android is so popular that supporting it would definitely be > interesting. There are a couple questions however (I'm not familiar > at all with Android, I don't have a smartphone ;-): - Do you have an > idea of the amount of work/patch size required? Do you have an > example of a patch (even if it's a work-in-progess)? - Is there > really a common Android platform? I've heard a lot about > fragmentation, so would we have to support several Android flavours > (like #ifdef __ANDROID_VENDOR_A__, #elif defined > __ANDROID_VENDOR_B__)? Absolutely! I maintain a public repository of patches against CPython v3.3.3 at [1]. They are divided into three large patches: one fixes some issues I encountered with CPython's build system for cross-compilation, one fixes Android/Bionic's numerous locale issues (locale.h/langinfo.h support in Android is basically a set of stub functions that return NULL), and the last one is a set of 'misc' fixes for things that affect Android, mainly smaller things like missing fields in struct passwd and the like. With those patches, CPython 3.3.3 will cross-compile to and run on at least my own Android device, a Moto G running Android 4.4.2. What's left to fail is fix the numerous regression test failures and their causes. I documented some of my findings at [2]. :) As far as Android fragmentation goes, to my knowledge that mainly refers to fragmentation at two levels: the Android versions numerous devices run tends to differ greatly, and the screen sizes, resolutions and aspect ratios vary greatly. Obviously the latter is a problem beyond the scope of CPython, but the former could lead to some issues. Luckily however, the NDK[3], the SDK of choice to use for C/C++-level applications, is fairly unified and expected to be used for pretty much all Android devices. Essentially there should be only the NDK for CPython to target, with a variety of NDK versions to support depending on which versions of Android CPython chooses to support. So far I've been only testing against NDK r9c, so I'm honestly not all that familiar with the changes different NDK versions bring, but from what I heard up until NDK r10 were mostly toolchain updates and header additions for new Android versions. I'd dare say that the vast, vast majority of Android devices out there are running on the same base, namely AOSP[4] with numerous vendor fixes/drivers/additions, and that custom Android distributions would try not to break NDK compatibility. Kind regards, Shiz [1]: https://github.com/rave-engine/python3-android/tree/master/src [2]: https://github.com/rave-engine/python3-android/issues/3 [3]: https://developer.android.com/tools/sdk/ndk/index.html [4]: https://source.android.com/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQQcBAEBCgAGBQJT29fZAAoJEICfd9ZVuxW+HaUf/1tBsrRckvIAdCyTfo1NjY/U fp8HJRh+mWUQ58dAy+jvaPxxQ4pTus5bsMZKw2LvSoC4aO4guqOydPBW4DVjdvJl m2ZegA3uGdgejoN/4gHpaQRU2Jq0KzRx3+ov3EuvPF8qZbGHelu/SjAWB+3zFH29 OrQsb8iX/p2RuuwcLlFF5ESO4ycYSRC8Pug8tUV+L8H2J9YU0ZyPzo1QsipNozzH k707RFa5xb34M3HINu/2ObT36mNsSHpOK+V268/Gst9VYwYnmgE//gen2vX2uaHi gqQMrd0eHBvaBdv48E681ytl9BHCN0X79fYDjKNCAZB/928UPy46qTtrvGxZ4ycR 2dCd0YURRMqRA8WeunkEHl9KYHWLsqex00RgwTgRXgJ+3gufeY4o2o5UH/JMW2te kMFqVN6S/ulzUF9clC1nLd5NFTq14e46kSckJdQJYscXghTmNf1D7CvnmwyOaYGo Ptq0vYaKcxGu3l1moFJCjqzz0unxBFMvEzkdY/YNXmtVjtrv66whcCAKIhPmrdgu DOsGt/UL5AtfiOcZv7ae9OyWvTd6+wqgWCj+sAxPA2hWEYkUZMju6lZP9OLAkXE7 UgPcjzRDTMPzr0DIBK0KyRxOYacHBb2dBidMqC9JqvKAlUpH132/YDz1LnFjdLj4 yxX6CztDHvdkxaCv1gTcvsyc+WJceUeiT+GGPtvDl/PoCy4pN4T+3NJp2EX21GNj md4OyLVps0lRGtAGAuGi3MwNI1CdSMrmqTt6YLsl8sM4GLbsr7CawULViA9N5Bup T/b/F46l9RXDAxj7T/PfTJHfByK6TrIJwP7ZBsryy1u6WIDUUu9hAETfOSze5P2d /RBzAieVbfctm41mZwvr1szFTTUJNVizlpti1Ab6874f3Hrn9h/06+MOGPBNEl2z 02JPVOUhpZqBvXdRvzyevOqVCWyN5WuVtGRY1hzP1/B06CSkbEHGbLXNE5GLqs4J q0wkpF47KMo+Jnbw+i9j5IrFCOP6S1Oqo8p0jPl/3C5JuLakF6F+w3mumJrxeClh BqvEsj2bpe+Su3tNc6msp/ifYH7GyLrya2BRs8B1SmOKuvLe2RuITPy6HXMqDRle v1wUHgUmTaTvpqxG7z3AQwf+r+p7eKKGOQA/NkvbnGMkiXBAyL1WYqkuZ4P05UIk Wpz+zKWZEdookd81drHrUw2ohMEFvrVpSvnWe4d/VLEsgObhS3t3gQRjvf804UuJ uMsqlOeNYDv/UPVoF12cJUOVONWchB7ACXbE7rt1Z8yf0p9sPlqM33aptB8tC4NE +tDUH4XRvWgw14PE7s7xBeTrElTHcJisQBXr5flBDsw6eMF1R4Bba3M4skqxpxs= =pMFQ -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
Re: [Python-Dev] Exposing the Android platform existence to Python modules
2014-08-01 13:23 GMT+01:00 Shiz : > >> Is your P.S. suggestive that you would not be willing to support your port >> for use by others? Of course, until it is somewhat complete, it is hard to >> know how complete and compatible it can be. > > Oh, no, nothing like that. It's just that I'm not sure, as goes for anything, > that it would be accepted into mainline CPython. Better safe than sorry in > that aspect: maybe the maintainers don't want to support Android in the first > place. :) Well, Android is so popular that supporting it would definitely be interesting. There are a couple questions however (I'm not familiar at all with Android, I don't have a smartphone ;-): - Do you have an idea of the amount of work/patch size required? Do you have an example of a patch (even if it's a work-in-progess)? - Is there really a common Android platform? I've heard a lot about fragmentation, so would we have to support several Android flavours (like #ifdef __ANDROID_VENDOR_A__, #elif defined __ANDROID_VENDOR_B__)? ___ 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
Re: [Python-Dev] Exposing the Android platform existence to Python modules
On 01 Aug 2014, at 03:54, Glenn Linderman wrote: > I've no idea what you mean by "userland" in your suggestions above or below, > but doesn't the Android environment qualify as a (multi-versioned) platform > independently of its host OS? Seems I've read about an Android > reimplementation for Windows, for example. As long as all the services > expected by Android are faithfully produced, the host OS may be irrelevant to > an Android application... in which case, I would think/propose/suggest the > platform name should change from win32 or linux to Android (and the Android > version be reflected in version parts). That might be a way to look at it. So far I assumed that the Android environment would be largely Linux-based, since the Android NDK (Native Development Kit, the SDK used for creating C/C++-level applications) is used for my patch which gives a GNU-ish toolchain with a Linux/Unixy environment. I know an implementation exists that claims to run Android on top of an NT kernel, but I honestly have little idea of how it works. Given how a fair amount of things ‘already work’ with the platform set to linux, I’m not sure if changing sys.platform would be a good idea… but that’s from my NDK perspective. > Is your P.S. suggestive that you would not be willing to support your port > for use by others? Of course, until it is somewhat complete, it is hard to > know how complete and compatible it can be. Oh, no, nothing like that. It’s just that I’m not sure, as goes for anything, that it would be accepted into mainline CPython. Better safe than sorry in that aspect: maybe the maintainers don’t want to support Android in the first place. :) Kind regards, Shiz signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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
Re: [Python-Dev] Exposing the Android platform existence to Python modules
> On 1 August 2014 02:54, Glenn Linderman wrote: > > Alternatively, if having sys.platform be "linux" makes portability > easier because code that does a platform check generally gets the > right answer if Android reports as "linux", then why not make > sys.linux_distribution report "android"? > > To put it briefly, either android is the platform, or android is a > specific distribution of the linux platform. > > Paul That might maybe work better. I was assuming a userland perspective because I’ve been honestly mostly wrestling with Bionic, Android’s libc, but putting that into perspective to consider Android as a whole (after all, the SDK and NDK are what make Android for a lot of developers) might be a valid other approach as well. Kinds regards, Shiz signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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
Re: [Python-Dev] Exposing the Android platform existence to Python modules
On 1 August 2014 02:54, Glenn Linderman wrote: > I've no idea what you mean by "userland" in your suggestions above or below, > but doesn't the Android environment qualify as a (multi-versioned) platform > independently of its host OS? Seems I've read about an Android > reimplementation for Windows, for example. As long as all the services > expected by Android are faithfully produced, the host OS may be irrelevant > to an Android application... in which case, I would think/propose/suggest > the platform name should change from win32 or linux to Android (and the > Android version be reflected in version parts). Alternatively, if having sys.platform be "linux" makes portability easier because code that does a platform check generally gets the right answer if Android reports as "linux", then why not make sys.linux_distribution report "android"? To put it briefly, either android is the platform, or android is a specific distribution of the linux platform. Paul ___ 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
Re: [Python-Dev] Exposing the Android platform existence to Python modules
On 7/31/2014 5:59 PM, Shiz wrote: Hi folks, I’m working on porting CPython to the Android platform, and while making decent progress, I’m currently stuck at a higher-level issue than adding #ifdefs for __ANDROID__ to C extension modules. The idea is, not only CPython extension modules have some assumptions that don’t seem to fit Android’s mold, some default Python-written modules do as well. However, whereas CPython extensions can trivially check if we’re building for Android by checking the __ANDROID__ compiler macro, Python modules can do no such check, and are left wondering how to figure out if the platform they are currently running on is an Android one. To my knowledge there is no reliable way to detect if one is using Android as a vehicle for their journey using any other way. Now, the main question is: what would be the best way to ‘expose’ the indication that Android is being ran on to Python-living modules? My own thought was to add sys.getlinuxuserland(), or platform.linux_userland(), in similar vein to sys.getwindowsversion() and platform.linux_distribution(), which could return information about the userland of running CPython instance, instead of knowing merely the kernel and the distribution. I've no idea what you mean by "userland" in your suggestions above or below, but doesn't the Android environment qualify as a (multi-versioned) platform independently of its host OS? Seems I've read about an Android reimplementation for Windows, for example. As long as all the services expected by Android are faithfully produced, the host OS may be irrelevant to an Android application... in which case, I would think/propose/suggest the platform name should change from win32 or linux to Android (and the Android version be reflected in version parts). This way, code could trivially check if it ran on the GNU(+associates) userland, or under a BSD-ish userland, or Android… and adjust its behaviour accordingly. I would be delighted to hear comments on this proposal, or better yet, alternative solutions. :) Kind regards, Shiz P.S.: I am well aware that Android might as well never be officially supported in CPython. In that case, consider this a thought experiment of how it /would/ be handled. :) Is your P.S. suggestive that you would not be willing to support your port for use by others? Of course, until it is somewhat complete, it is hard to know how complete and compatible it can be. ___ 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
[Python-Dev] Exposing the Android platform existence to Python modules
Hi folks, I’m working on porting CPython to the Android platform, and while making decent progress, I’m currently stuck at a higher-level issue than adding #ifdefs for __ANDROID__ to C extension modules. The idea is, not only CPython extension modules have some assumptions that don’t seem to fit Android’s mold, some default Python-written modules do as well. However, whereas CPython extensions can trivially check if we’re building for Android by checking the __ANDROID__ compiler macro, Python modules can do no such check, and are left wondering how to figure out if the platform they are currently running on is an Android one. To my knowledge there is no reliable way to detect if one is using Android as a vehicle for their journey using any other way. Now, the main question is: what would be the best way to ‘expose’ the indication that Android is being ran on to Python-living modules? My own thought was to add sys.getlinuxuserland(), or platform.linux_userland(), in similar vein to sys.getwindowsversion() and platform.linux_distribution(), which could return information about the userland of running CPython instance, instead of knowing merely the kernel and the distribution. This way, code could trivially check if it ran on the GNU(+associates) userland, or under a BSD-ish userland, or Android… and adjust its behaviour accordingly. I would be delighted to hear comments on this proposal, or better yet, alternative solutions. :) Kind regards, Shiz P.S.: I am well aware that Android might as well never be officially supported in CPython. In that case, consider this a thought experiment of how it /would/ be handled. :) signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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
