<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Dec 30, 2014 at 5:34 PM, Russell Keith-Magee <span dir="ltr"><<a href="mailto:russell@keith-magee.com" target="_blank">russell@keith-magee.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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.</div></div></div></div></blockquote><div><br></div><div>Thanks for the clarification -- it does sound like they are headed in the right direction, then. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>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).</div></div></div></div></blockquote><div><br></div><div>sounds good -- and you are right, the core building stuff should be in the main source. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>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.?</div></div></div></div></blockquote><div><br></div></span><div>That approach might work. However, py2app etc are just optimizations - you still need to have all the language bindings etc.</div></div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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....</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>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</div></div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>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.<br></div></div></div></div></blockquote></span><div><br></div><div>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.</div></div></div></div></blockquote><div><br></div><div>yup -- I'm really looking forward to the results of your work!</div><div><br></div><div>-Chris</div><div> </div></div><div><br></div>-- <br><div class="gmail_signature"><br>Christopher Barker, Ph.D.<br>Oceanographer<br><br>Emergency Response Division<br>NOAA/NOS/OR&R (206) 526-6959 voice<br>7600 Sand Point Way NE (206) 526-6329 fax<br>Seattle, WA 98115 (206) 526-6317 main reception<br><br><a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a></div>
</div></div>