From russell at keith-magee.com Sun Mar 1 00:35:26 2015 From: russell at keith-magee.com (Russell Keith-Magee) Date: Sun, 1 Mar 2015 07:35:26 +0800 Subject: [Mobile-sig] python on android In-Reply-To: References: <54F0B5CF.4090901@stoneleaf.us> Message-ID: On Sat, Feb 28, 2015 at 10:07 AM, Wes Turner wrote: > > > On Fri, Feb 27, 2015 at 6:40 PM, Russell Keith-Magee < > russell at keith-magee.com> 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. My read on the situation is that os.name should return 'posix', but sys.platform is supposed to be "detailed checks for the system?s identity" [1] [1] https://docs.python.org/2/library/os.html Maybe an additional sys.mobile_platform would be more helpful? > This is of course the other option. However, what does sys.mobile_platform return on a desktop machine? And what about something like Ouya, which is Android, but isn't really a "mobile" platform. 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. However, I appreciate that this isn't a question of absolutes; it is, at some level a judgement call, and may require a BDFL (or delegate) to make a call. Yours, Russ Magee %-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From wes.turner at gmail.com Sun Mar 1 02:38:39 2015 From: wes.turner at gmail.com (Wes Turner) Date: Sat, 28 Feb 2015 19:38:39 -0600 Subject: [Mobile-sig] python on android In-Reply-To: References: <54F0B5CF.4090901@stoneleaf.us> Message-ID: On Sat, Feb 28, 2015 at 5:35 PM, Russell Keith-Magee < russell at keith-magee.com> wrote: > > On Sat, Feb 28, 2015 at 10:07 AM, Wes Turner wrote: > >> >> >> On Fri, Feb 27, 2015 at 6:40 PM, Russell Keith-Magee < >> russell at keith-magee.com> 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). > My read on the situation is that os.name should return 'posix', but > sys.platform is supposed to be "detailed checks for the system?s identity" > [1] > > [1] https://docs.python.org/2/library/os.html > > Maybe an additional sys.mobile_platform would be more helpful? >> > > This is of course the other option. However, what does sys.mobile_platform > return on a desktop machine? And what about something like Ouya, which is > Android, but isn't really a "mobile" platform. > Good point. > > 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. > > However, I appreciate that this isn't a question of absolutes; it is, at > some level a judgement call, and may require a BDFL (or delegate) to make a > call. > > Again, reasonable development build environments (for CI) would be helpful. -------------- next part -------------- An HTML attachment was scrubbed... URL: From russell at keith-magee.com Tue Mar 3 02:14:45 2015 From: russell at keith-magee.com (Russell Keith-Magee) Date: Tue, 3 Mar 2015 09:14:45 +0800 Subject: [Mobile-sig] python on android In-Reply-To: References: <54F0B5CF.4090901@stoneleaf.us> Message-ID: On Sun, Mar 1, 2015 at 9:38 AM, Wes Turner wrote: > > > On Sat, Feb 28, 2015 at 5:35 PM, Russell Keith-Magee < > russell at keith-magee.com> wrote: > >> >> On Sat, Feb 28, 2015 at 10:07 AM, Wes Turner >> wrote: >> >>> >>> >>> On Fri, Feb 27, 2015 at 6:40 PM, Russell Keith-Magee < >>> russell at keith-magee.com> 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 %-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ethan at stoneleaf.us Tue Mar 3 02:20:58 2015 From: ethan at stoneleaf.us (Ethan Furman) Date: Mon, 02 Mar 2015 17:20:58 -0800 Subject: [Mobile-sig] python on android In-Reply-To: References: <54F0B5CF.4090901@stoneleaf.us> Message-ID: <54F50C7A.5030707@stoneleaf.us> On 03/02/2015 05:14 PM, Russell Keith-Magee wrote: > 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. I am strongly leaning towards having sys.platform == 'android' (and whatever is appropriate for the iDevices) . -- ~Ethan~ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From wes.turner at gmail.com Tue Mar 3 02:23:23 2015 From: wes.turner at gmail.com (Wes Turner) Date: Mon, 2 Mar 2015 19:23:23 -0600 Subject: [Mobile-sig] python on android In-Reply-To: References: <54F0B5CF.4090901@stoneleaf.us> Message-ID: 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" wrote: > > On Sun, Mar 1, 2015 at 9:38 AM, Wes Turner wrote: > >> >> >> On Sat, Feb 28, 2015 at 5:35 PM, Russell Keith-Magee < >> russell at keith-magee.com> wrote: >> >>> >>> On Sat, Feb 28, 2015 at 10:07 AM, Wes Turner >>> wrote: >>> >>>> >>>> >>>> On Fri, Feb 27, 2015 at 6:40 PM, Russell Keith-Magee < >>>> russell at keith-magee.com> 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 %-) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From russell at keith-magee.com Tue Mar 3 04:16:53 2015 From: russell at keith-magee.com (Russell Keith-Magee) Date: Tue, 3 Mar 2015 11:16:53 +0800 Subject: [Mobile-sig] python on android In-Reply-To: References: <54F0B5CF.4090901@stoneleaf.us> Message-ID: On Tue, Mar 3, 2015 at 9:23 AM, Wes Turner 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" > wrote: > >> >> On Sun, Mar 1, 2015 at 9:38 AM, Wes Turner wrote: >> >>> >>> >>> On Sat, Feb 28, 2015 at 5:35 PM, Russell Keith-Magee < >>> russell at keith-magee.com> wrote: >>> >>>> >>>> On Sat, Feb 28, 2015 at 10:07 AM, Wes Turner >>>> wrote: >>>> >>>>> >>>>> >>>>> On Fri, Feb 27, 2015 at 6:40 PM, Russell Keith-Magee < >>>>> russell at keith-magee.com> 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 %-) >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From russell at keith-magee.com Sun Mar 15 07:37:39 2015 From: russell at keith-magee.com (Russell Keith-Magee) Date: Sun, 15 Mar 2015 14:37:39 +0800 Subject: [Mobile-sig] First attempt at a patch for official iOS support Message-ID: Hi all, (after a false start due to accidentally hitting send...) I've just created Python ticket 23670, tracking the proposal to add iOS support to Python. http://bugs.python.org/issue23670 The patch isn't quite trunk ready, for reasons detailed on the ticket - but it is a single patch against 3.4.2 sources, requiring no pre- or post-configure modifications. There is also a helper Makefile to manage the complexities of an iOS build. I'd appreciate any feedback. Yours, Russ Magee %-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From russell at keith-magee.com Sun Mar 15 07:34:22 2015 From: russell at keith-magee.com (Russell Keith-Magee) Date: Sun, 15 Mar 2015 14:34:22 +0800 Subject: [Mobile-sig] First attempt at a patch for iOS support Message-ID: Hi all, I've just created Python ticket -------------- next part -------------- An HTML attachment was scrubbed... URL: From sunfish7 at gmail.com Mon Mar 23 16:39:48 2015 From: sunfish7 at gmail.com (=?utf-8?B?z4A=?=) Date: Mon, 23 Mar 2015 15:39:48 +0000 Subject: [Mobile-sig] Python3 + stdlib on iOS, Android Message-ID: <22734763-B909-4A56-A976-561A37D12637@gmail.com> Hello all, I'm designing a multiplatform C++ application which embeds Python3. So far I have it working on OS X. I've copied the libpython into my project directory and linked against it. I'm able to launch a Python interpreter, use the C-API, etc. (Incidentally I've open-sourced my Python-C++ bridge here: https://github.com/p-i-/PiCxx ) I'm concerned about porting my project to iOS/Android in the future. The Kivy developers have successfully built Python2.x + stdlib for iOS/Android. They plan to eventually to also support 3.x, but it is not a priority for them at the moment. And to my knowledge nobody else has successfully ported 3.x. Does anyone know otherwise? Using Python2 (from Kivy) would be awkward because my C++ Python Interface code targets Python 3.x, and it would take a lot of work to add 2.x support. There was talk on here a while back regarding Python3 on iOS, but I don't remember any mention of stdlib. >>> p(sys.path) ['', '/usr/local/Frameworks/Python.framework/Versions/3.4/lib/python34.zip', '/usr/local/Frameworks/Python.framework/Versions/3.4/lib/python3.4', '/usr/local/Frameworks/Python.framework/Versions/3.4/lib/python3.4/plat-darwin', '/usr/local/Frameworks/Python.framework/Versions/3.4/lib/python3.4/lib-dynload', '/usr/local/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages', '/usr/local/lib/python3.4/site-packages'] ^ that is from an interactive Python prompt within my C++ app. If I were to build on iOS, none of this would exist. lib-dynload contains 50 or so .so files which are compiled Python extension objects. If I understand correctly, this makes up much of Python's stdlib -- the remainder being .py files. So it would be necessary to compile these for iOS/Android. I'm told Python's compile process simultaneously compiles the libpython and these .so files. So maybe whoever has got that working on iOS has successfully created these .so-s. Or maybe they compiled with all modules turned off? And as for Android, I have no idea whether this has been done. Can anyone help me understand the work that is required here, and how to set about going at it? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.i.frank at intel.com Mon Mar 23 16:54:33 2015 From: matthew.i.frank at intel.com (Frank, Matthew I) Date: Mon, 23 Mar 2015 15:54:33 +0000 Subject: [Mobile-sig] Python3 + stdlib on iOS, Android In-Reply-To: <22734763-B909-4A56-A976-561A37D12637@gmail.com> References: <22734763-B909-4A56-A976-561A37D12637@gmail.com> Message-ID: <8FEF00DDD6C58843BF4ED3C1DCF80E9F6EB011E9@fmsmsx120.amr.corp.intel.com> On 2015-03-23-10:40 CDT, ? wrote > So far I have it working on OS X. I've copied the libpython into my project > directory and linked against it. I'm able to launch a Python interpreter, > use the C-API, etc. > > (Incidentally I've open-sourced my Python-C++ bridge here: > https://github.com/p-i-/PiCxx) > > I'm concerned about porting my project to iOS/Android in the future. > > The Kivy developers have successfully built Python2.x + stdlib for > iOS/Android. They plan to eventually to also support 3.x, but it is not a > priority for them at the moment. > > And to my knowledge nobody else has successfully ported 3.x. > > Does anyone know otherwise? For iOS you should try Russ Magee's patch here: http://bugs.python.org/issue23670 For Android, I've been trying to put something together here: https://github.com/wandering-logic/android_x86_python-3.4 These are both Python 3 and include as much of the Standard Library as possible. (In the case of Android I've got the entire Standard Library compiling, but a few parts of it (e.g. ctypes) aren't passing their regression tests yet. (See the github page for the regression tests that are still failing). -Matt From russell at keith-magee.com Tue Mar 24 01:01:50 2015 From: russell at keith-magee.com (Russell Keith-Magee) Date: Tue, 24 Mar 2015 08:01:50 +0800 Subject: [Mobile-sig] Python3 + stdlib on iOS, Android In-Reply-To: <8FEF00DDD6C58843BF4ED3C1DCF80E9F6EB011E9@fmsmsx120.amr.corp.intel.com> References: <22734763-B909-4A56-A976-561A37D12637@gmail.com> <8FEF00DDD6C58843BF4ED3C1DCF80E9F6EB011E9@fmsmsx120.amr.corp.intel.com> Message-ID: On Mon, Mar 23, 2015 at 11:54 PM, Frank, Matthew I < matthew.i.frank at intel.com> wrote: > On 2015-03-23-10:40 CDT, ? wrote > > So far I have it working on OS X. I've copied the libpython into my > project > > directory and linked against it. I'm able to launch a Python interpreter, > > use the C-API, etc. > > > > (Incidentally I've open-sourced my Python-C++ bridge here: > > https://github.com/p-i-/PiCxx) > > > > I'm concerned about porting my project to iOS/Android in the future. > > > > The Kivy developers have successfully built Python2.x + stdlib for > > iOS/Android. They plan to eventually to also support 3.x, but it is not > a > > priority for them at the moment. > > > > And to my knowledge nobody else has successfully ported 3.x. > > > > Does anyone know otherwise? > > For iOS you should try Russ Magee's patch here: > http://bugs.python.org/issue23670 > One caveat that is mentioned in the ticket, but I'll repeat here for clarity - the patch on that ticket doesn't work for ARMv7 processors at present. There's a known bug preventing ctypes from compiling on ARMv7. However, it works on both the simulator and ARM64 devices, and the bug on ARMv7 is a known quantity. There's no fundamental problem with ARMv7 - it's just that you need to use a trunk version of libffi to get working ARM64 support, but that version is broken for ARMv7. If you use an older libffi, you get working ARMv7, but break ARM64 support. I've got a separate Github project to provide some build support tools - see https://github.com/pybee/Python-iOS-support As a side note - if anyone knows how to get hold of Anthony Green (the libffi lead), or anyone else on the libffi team - I'd appreciate help in contacting him. Every message I send to the libffi mailing list bounces off their spam detector (sending from a normal Gmail account), and private mails/twitter messages to Anthony have gone unanswered. Or, if someone knows enough about x86 assembler to address [1]... [1] https://github.com/atgreen/libffi/issues/181 Yours, Russ Magee %-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rotoglup at gmail.com Wed Mar 25 17:18:24 2015 From: rotoglup at gmail.com (Nicolas Lelong) Date: Wed, 25 Mar 2015 17:18:24 +0100 Subject: [Mobile-sig] Python3 + stdlib on iOS, Android Message-ID: Sorry if this email ends up in a wrong thread, I just subscribed and can't 'reply'. As a side note - if anyone knows how to get hold of Anthony Green... I've had an experience exchanging with him in 2012 in a github pull request for iOS in libffi ; he was pretty reactive at that time, but also mentionned the following : "I am not a Mac user, and until somebody buys me one I'm unlikely to have > any strong opinions as to how libffi should be built for OSX or iOS, as > long as it is useful. I'm not opposed to having multiple build mechanisms > in place if people are willing to contribute and maintain them. I'm > looking for guidance here..." FWIW, I guess any iOS issue is unlikely to be fixed by Anthony, but I'm sure he'll gladly accept pull requests. -------------- next part -------------- An HTML attachment was scrubbed... URL: From russell at keith-magee.com Thu Mar 26 00:53:56 2015 From: russell at keith-magee.com (Russell Keith-Magee) Date: Thu, 26 Mar 2015 07:53:56 +0800 Subject: [Mobile-sig] Python3 + stdlib on iOS, Android In-Reply-To: References: Message-ID: On Thu, Mar 26, 2015 at 12:18 AM, Nicolas Lelong wrote: > Sorry if this email ends up in a wrong thread, I just subscribed and can't > 'reply'. > > As a side note - if anyone knows how to get hold of Anthony Green... > > > I've had an experience exchanging with him in 2012 in a github pull > request for iOS in libffi ; he was pretty reactive at that time, but also > mentionned the following : > > "I am not a Mac user, and until somebody buys me one I'm unlikely to have >> any strong opinions as to how libffi should be built for OSX or iOS, as >> long as it is useful. I'm not opposed to having multiple build mechanisms >> in place if people are willing to contribute and maintain them. I'm >> looking for guidance here..." > > > FWIW, I guess any iOS issue is unlikely to be fixed by Anthony, but I'm > sure he'll gladly accept pull requests. > I don't know what sort of delay you consider "reactive", but I've got 2 fairly simple pull requests that are now almost 2 weeks old, neither of which have even been commented on: https://github.com/atgreen/libffi/pull/186 https://github.com/atgreen/libffi/pull/185 However, that doesn't especially concern me - I know all too well that open source development often comes in fits and bursts as other things take priority. My bigger concern is that I can't post to the project mailing list, and I can't contact anyone who will discuss the problem I'm having with the project mailing list. The trunk of the libffi repository is demonstrably and repeatably broken for ARM, and it's not clear that anyone in charge of cutting releases is aware of this fact - again, there's a ticket that is a month old, and there's been no comment on it. Yours, Russ Magee %-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rotoglup at gmail.com Thu Mar 26 07:52:19 2015 From: rotoglup at gmail.com (Nicolas Lelong) Date: Thu, 26 Mar 2015 07:52:19 +0100 Subject: [Mobile-sig] Python3 + stdlib on iOS, Android In-Reply-To: References: Message-ID: I see, Regarding the 'spam' issue with the libffi mailing list, did you try the workarounds indicated here ? https://sourceware.org/lists.html#spam Nicolas -------------- next part -------------- An HTML attachment was scrubbed... URL: From russell at keith-magee.com Thu Mar 26 08:13:05 2015 From: russell at keith-magee.com (Russell Keith-Magee) Date: Thu, 26 Mar 2015 15:13:05 +0800 Subject: [Mobile-sig] Python3 + stdlib on iOS, Android In-Reply-To: References: Message-ID: I had no idea that page existed. I can't find any link to it from the libffi project page, or the libffi mailing list archive (which is itself pretty well hidden). Thanks for the pointer - I'll try it and see what happens. Yours, Russ Magee %_) On Thu, Mar 26, 2015 at 2:52 PM, Nicolas Lelong wrote: > I see, > > Regarding the 'spam' issue with the libffi mailing list, did you try the > workarounds indicated here ? > > https://sourceware.org/lists.html#spam > > Nicolas > -------------- next part -------------- An HTML attachment was scrubbed... URL: