[Python-ideas] python on mobile

[Andrew Barnert]

On Dec 26, 2014, at 15:49, "Stephen J. Turnbull" <stephen at xemacs.org> wrote:

> Fetchinson . writes:
> 
>> Hi all, maybe the best list would be python-dev
> 
> No, this is the right place if you eventually want to get Python-Dev
> involved.  It's not obvious that's the right thing to do, though,
> since that list's primary development environment (for the
> interpreter) is C.  Android might work better with a Jython
> derivative, and I don't know what would be the right environment to
> develop for iOS.  

For iOS, it's probably CPython or a CPython derivative. (The whole point of ObjC is that yet includes C and can run C libraries like libpython natively, and the platform is a Unix+Cocoa platform very similar to OS X.)


> So perhaps mobile platforms would develop as
> independent implementations of Python-the-Language like Jython or
> IronPython, rather than as a branch of CPython.
> 
> Also, as Sturla points out, it might be better to use something like
> Cython.
> 
>> So my question is this: is there a coherent mobile strategy among
>> core dev people?
> 
> Not yet.  Until recently (say a couple years ago), Apple officially
> forbid use of non-blessed languages on iDevices.  Android was a little
> more friendly in principle but there are stringent restrictions for
> security reasons that require rethinking concepts that involve
> interactions with the OS.  These mobile ports hardly get mentioned on
> python-dev or on this list.
> 
>> Or there are some issues which preclude this from the start?
> 
> I think there are a lot of people who would like to see something
> solid.  But AFAICS the problem is more the lack of interest (ie, no
> promise that something that works today will work tomorrow) from the
> OS vendors than the lack of interest from core, plus the resources
> constraints Sturla mentions, which I suppose would make programming
> Python on a mobile device less fun.  That would also help explain the
> proliferation of different implementations, as each would have its own
> approach to working around the resource restrictions.
> 
> So I would say there's no "preclusion", but it's an uphill road for
> now.

Cross-compiling CPython itself, and most of the stdlib, is dead easy, at least for iOS. (I'll ignore Android, and other mobile platforms, but at least some things are similar.) And building an ObjC app that embeds CPython is also pretty easy. So for that part, there's very little for the core devs to do beyond listing it as a standard target and adding tests for it. CPython could I suppose also have an official (Mac) installer for a cross-compiled Python for iOS, which would also be pretty easy if anyone wanted it. But I think the problem is that nobody wants this, except for a small community of people 98% of whom have no problem building Python themselves.

A standard iOS GUI might be nice, but CPython includes only Tkinter, which doesn't work on iOS and almost certainly never will, and I don't think you'd want to use it anyway. I think incorporating a different GUI framework is way out of scope for the core distribution--or, if not, it should be done for desktop first. (It would be silly to have PyQt for iOS but not for Linux.)

Building an app bundle for iOS is painful on iOS, but it's just as painful on Windows and OS X, and even more so on Linux, which is why people use third-party tools like py2app and pyInstaller. Again, if those tools aren't in scope for the core distribution, building similar tools for mobile is even less so.

Finally, cross-compiling C extensions had a few frustrations. Some of this is just bugs, which people will continue to find, file, and fix. But the big problem is that there isn't some standard set of steps that works for every package to use your native Python to build extensions for a cross-compiled Python and install them into its stdlib. When you compare how simple that is for native Python (pip install spam), there's clearly a lot of room for improvement. But I suspect the packaging SIG rather than -ideas is the place to get started there. Or maybe even come up with a design for a setuptools-cross library and pip-cross tool and put up a prototype first, and the try to get it standardized?

Still, I don't think that'll relieve the need for things like Kivy. If you're looking to build an app for iOS, even with a standard installation, a pip-cross, a py2app-iOS, and cross wheels for, say, a statically-linked PyQt, anyone who isn't already Qt-savvy or looking to port a desktop (or Qtopia) app is likely to be happier with something like Kivy in multiple ways. Which is fine. But that implies that maybe the most important thing for the core devs to do is to help
Kivy and similar teams with whatever blocking frustrations they have due to
core CPython limitations, rather than trying to build something from the ground up.