<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Sun, Oct 26, 2014 at 4:58 AM, Andrew Barnert <span dir="ltr"><<a href="mailto:abarnert@yahoo.com" target="_blank">abarnert@yahoo.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On Oct 24, 2014, at 19:20, Russell Keith-Magee <<a href="mailto:russell@keith-magee.com">russell@keith-magee.com</a>> wrote:<br>
<br>
> I'd like to start supporting more recent versions of Python - most importantly, Python 3. While I could certainly continue maintaining patches externally (and I imagine I'll have to if I want to maintain Python 2.7 support), I'd like to see that effort integrated into Python's repository.<br>
<br>
</span>People have already been making Python 3 builds for iOS, wrapping them in mini-IDEs, and selling them on the App Store for quite some time. Have you talked to Xiaowen Huang or any of the others?<br>
<br>
As far as I know, most of them build Python as a static lib, and link in the C extensions from the stdlib, to get around the issues with shared-lib frameworks before iOS 8. And I'm not sure how they deal with third-party modules (at least one of them includes numpy, for example).<br>
<br>
You also may want to talk to whoever maintains the ports for jailbroken iOS, because that's just a standard-as-possible build, with the command line interpreter and pip and everything.<span class=""><br></span></blockquote><div><br></div><div>To clarify - this isn't a theoretical thing - I've got a Python 2.7 static library running on non-jailbroken iOS and Android devices, and I've published the tools (and builds) to let others do the same:</div><div><br></div><div><a href="https://github.com/pybee/Python-iOS-support">https://github.com/pybee/Python-iOS-support</a><br></div><div><a href="https://github.com/pybee/Python-Android-support">https://github.com/pybee/Python-Android-support</a><br></div><div><br></div><div>And I've published cookiecutter templates for iOS and Android projects if you want to write your apps in Python:</div><div><br></div><div><a href="https://github.com/pybee/Python-iOS-template">https://github.com/pybee/Python-iOS-template</a><br></div><div><a href="https://github.com/pybee/Python-Android-template">https://github.com/pybee/Python-Android-template</a><br></div><div><br></div><div>The support libraries are mostly patches and build system tweaks, and at present, they're all for stale versions of Python 2.7. I'm on Python-ideas because I want to move as much as possible back upstream into Python's sources.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
> In particular, there are four areas where I can see changes required:<br>
><br>
>  1) At least 2 new sys.platform definitions - "ios" and "android" (a third "iossimulator" platform might also be needed - the iOS simulator has enough differences that it can be helpful to be able to identify the platform)<br>
<br>
</span>There are other fields in platform and sys that can be used to distinguish iOS from the simulator. And, since you need to check iOS simulator or real iOS vs. everything else at least as often as you need to distinguish them from each other, I'm not sure it's important whether it's treated as a separate platform or a different version of the same platform--as long as there's some documented and guaranteed way to distinguish them.<span class=""><br></span></blockquote><div><br></div><div>That's a good point; I'll investigate what can be done using other fields in platform and sys.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
>  3) Disabling certain modules on mobile platforms. Supporting modules like linuxaudiodev, ossaudiodev, readline, curses, idle and tkinter on mobile platforms doesn't make much sense; modules likes bsddb and bz2 are difficult to support due to library dependencies; and the need for modules like multiprocessing is arguable (and difficult to support on mobile). Even providing a Python executable/shell is arguable for these platforms.<br>
<br>
</span>How is multiprocessing difficult to provide on mobile? iOS has had fork, posix_spawn, semaphores, etc. since the first release with an SDK, although you'd get rejected from the App Store for using them in the early days. Of course Apple would prefer people to use XPC via grand central, but that doesn't mean you need to make it impossible to use fork instead; at most, you just need to warn people to read the App Store guidelines.<br>
<br>
In the opposite direction, it might be worth looking at the "extra batteries" in Apple's OS X builds. At least PyObjC seems like something you'd want to get working on iOS.<span class=""><br></span></blockquote><div> </div><div>I looked at PyObjC; I was unsatisfied with the performance, and it has a native compiled component. I ended up writing my own ObjC bindings, based off an initial collection of code from Pyglet:</div><div><br></div><div><a href="https://github.com/pybee/rubicon-objc">https://github.com/pybee/rubicon-objc</a><br></div><div><br></div><div>This uses ctypes, so there's no compiled component.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
> I have no idea how to tackle 4. To create a complete iOS build, you have to do at least 4 complete Python builds - a native system build (so you can run Python scripts that are part of the build), an i386 build (for the simulator), an armv7 build, and an arm64 build - and then the build products of the last three need to be combined into a single framework directory.<br>
><br>
> Given three independent platform-specific build directories, it's relatively easy to construct a "fat" framework, but it isn't clear to me how that would fit into Python's build system. I can see that the build system has support for "universal" builds, which looks like an artefact of the OS X PPC->i386 conversion, but the build approach appears to be different to that required for iOS.<br>
<br>
</span>It's still perfectly possible to build Python universal on OS X. In fact, both the <a href="http://python.org" target="_blank">python.org</a> builds and Apple's pre-installed builds are fat i386/x86_64.<br></blockquote><div> </div><div>Yes, but AFAICT, this is done by leveraging the ability of clang to compile a binary that supports multiple architectures at once.. The iOS toolchain doesn't do that (AFAICT) - you need to build separately and lipo the products together. OSX only needs a single compiler pass; iOS needs multiple passes.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
iOS does put some limitations on things, especially when building shared libs, but if you need to fall back to building each target separately and lipo'ing them together manually, I'm pretty sure there are a few third-party libs that already use that workaround. Didn't PyObjC used to build that way?</blockquote></div><br></div><div class="gmail_extra">I'll take a closer look at PyObjC's build process and see what I can work out.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Yours,</div><div class="gmail_extra">Russ Magee %-)</div><div class="gmail_extra"><br></div></div>