[Python-ideas] python on mobile

Chris Barker chris.barker at noaa.gov
Wed Dec 31 18:01:58 CET 2014

On Tue, Dec 30, 2014 at 5:34 PM, Russell Keith-Magee <
russell at keith-magee.com> wrote:

> Incorrect. On both iOS and Android, Kivy uses Cython as the mechanism to
> get a C-native platform binding (PyJNIus/PyObjCus) that allows your Python
> code to invoke native libraries directly. The deployed app is a Python
> interpreter that is packaged with all the Python code and libraries, and
> it's executed as byte code at runtime.

Thanks for the clarification -- it does sound like they are headed in the
right direction, then.

Sure, it could be done. And in a sense, that *is* what I'm doing - taking
> all the Kivy-specific parts out of Kivy's tools. And what I've been left
> with is things that, IMHO, should be in Python's own source tree. Along the
> way, I've discovered all the ways that Kivy's tools are deficient (for
> example, as a result of the way they've done their build, sys.platform
> reports the compilation platform, not the runtime platform).

sounds good -- and you are right, the core building stuff should be in the
main source.

> But is it better to target getting Python running on Mobile just like it
>> does on the desktop: you have a python interpreter, a bunch of python
>> modules, and you bundle it all up with a executable launcher of some sort,
>> al la py2exe, py2app, etc.?
> That approach might work. However, py2app etc are just optimizations - you
> still need to have all the language bindings etc.

well, they are not optimizations, exactly, but they are extra stuff -- the
final bundling up as an app. The thing is, that that last stage is
optional, and as far as I can tell, a small fraction of the python use
cases, for current python use. But for mobile, it is essential: no one is
going to be delivering an app that first requires you to install a python
environment and associated packages for your iPhone.

Of course, it still requires the basic python environment and standard
library to be built in a way that makes sense, but some of that way that
makes sense may be influenced by the target delivery method. I"d love to
see the bundling be standardized as well, but that probably isn't a project
for the core development team.

Though maybe it is -- the truth is that Python does not currently "have a
story" on Mobile. And a real "story" would be a soup to nuts -- this is how
you build an app with python for iOS/Android/WindowsMobile. If we can only
say: cPython compiles fine for mobile platforms, but you still need to
figure out how to call system libs, and bundle it up as an app, and here
are a dozen scattered projects that all do that differently, each designed
for a different use case, We really aren't there.

All that being said, it seems you are very much on the right track -- start
at the bottom, if you can get the core building stuff in the standard
distribution, then at least the dozen different systems could b built on
the same python....

> As for the "Apple" factor - that's not an issue (at least, not at the
> moment). Apple doesn't place restrictions on "interpreted" apps in the app
> store, as long as the scripts are all bundled as part of the app

However, I can't see that one could build a python "run time" that
individual apps could all share, rather than each app bundling up python
and all with it. Maybe flash space and RAM is cheap enough these days that
we don't care but it is still a bit constrained on mobile.

I'm aware of the approach - I've even used it myself in the past (to get a
>> UI on an old iPaq handheld). However, once you've got a working Python
>> interpreter on mobile with good bindings to the underlying platform, it
>> shouldn't be too hard to write - getting a WebKit view that consumes the
>> entire screen is easy to write, no matter what platform you're on, so then
>> you just need to set up the server stuff, and for that all you need is a
>> Python interpreter with a working socket and threads module. I'm not sure
>> it would be great for battery life, but that's a separate problem.
> I can't say that particular approach something I'm particularly interested
> in myself, but my point is that this shouldn't matter - once you can do
> Python on mobile, it's up to you to decide what works or doesn't. But the
> first step is getting Python supported on mobile.

yup -- I'm really looking forward to the results of your work!



Christopher Barker, Ph.D.

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20141231/7867e79d/attachment-0001.html>

More information about the Python-ideas mailing list