Hi all, maybe the best list would be python-dev but I don't dare waking the sleeping lions there :) So my question is this: is there a coherent mobile strategy among core dev people? I mean you guys release python for linux/macos/windows and the question is if there are any plans to do the same for a mobile platform. It doesn't have to be android or ios just anything that the core dev team chooses and sticks with. I've been developing python apps for smartphones (mostly hobby projects though) using sl4a but that seems like is dead. Now people suggest me using kivy which seems to be alive but who knows how long. There are some other projects qpython, etc, which are small and equally not so reliable at least looking from the outside. Is kivy now an officially blessed distribution? Since google was so integral to both python (through employing Guido) and android I'd think it would make sense for google to have an official python environment for android in cooperation with the python dev team. Does the PSF has an opinion on this? It would be great if there would be something for mobile phones that we could rely on not going away just as with linux/macos/windows. Or there are some issues which preclude this from the start? Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown
Some thoughs on this: Kivy is based on PyGame, which is based on SDL (libsdl.org), PyOpenGL and NumPy. SDL is not going away and supports iOS and Android as well as most deskop OSes. PyOpenGL and NumPy are not going away either. Personally I would consider to use SDL and OpenGL directly from Cython, unless you really need Kivy. A mobile has limited resources so you should be careful about stacking up several layers of software. You can use Objective C APIs directly in Python with PyObjC, and thereby create "native" iOS apps. PyQt now supports Qt5 and has official iOS and Android support. You might also try your luck with PySide. Beware of the licensing issues. There is something called HTML5. I don't know much about it, but presumably you can use WebKit Framework in yout iOS Python app to make an HTML5 based UI. Mozilla is now coming to iOS and Android. Using Python and XUL might also be possible. There are apps in Apple Appstore based on Python co clearly it can be done. As I understand the rules now the app bundle must be self-contained. I.e. you must include the Python interpreter and all libraries in the bundle. Also your app cannot download executable code (e.g. python modules) from the internet. The used to be a ban on interpreted code on iOS, but I think that was mostly to fight Adobe Flash and Java mobile edition. The requirement now is a self-contained app bundle. Sturla On 26/12/14 11:34, Fetchinson . wrote:
Hi all, maybe the best list would be python-dev but I don't dare waking the sleeping lions there :)
So my question is this: is there a coherent mobile strategy among core dev people? I mean you guys release python for linux/macos/windows and the question is if there are any plans to do the same for a mobile platform. It doesn't have to be android or ios just anything that the core dev team chooses and sticks with.
I've been developing python apps for smartphones (mostly hobby projects though) using sl4a but that seems like is dead. Now people suggest me using kivy which seems to be alive but who knows how long. There are some other projects qpython, etc, which are small and equally not so reliable at least looking from the outside. Is kivy now an officially blessed distribution? Since google was so integral to both python (through employing Guido) and android I'd think it would make sense for google to have an official python environment for android in cooperation with the python dev team.
Does the PSF has an opinion on this? It would be great if there would be something for mobile phones that we could rely on not going away just as with linux/macos/windows.
Or there are some issues which preclude this from the start?
Cheers, Daniel
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. 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.
On Dec 26, 2014, at 15:49, "Stephen J. Turnbull" <stephen@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.
Hi Daniel, I've been working on this problem recently; I posted about the idea to this very list a few months ago: https://mail.python.org/pipermail/python-ideas/2014-October/029856.html At the time I posted, I had posted Python builds that work on both Android and iOS: https://github.com/pybee/Python-iOS-support https://github.com/pybee/Python-Android-support and template projects that get you to "hello world" on a mobile platform without much effort. https://github.com/pybee/Python-iOS-template https://github.com/pybee/Python-Android-template I've also tackled the cross-language bridging issue: https://github.com/pybee/rubicon-objc https://github.com/pybee/rubicon-java and wrapped native widgets up into a cross-platform widget library: http://pybee.org/toga/ Now - I'm not claiming that these are anywhere near production ready - they're proof of concept at best. However, I completely agree with your original premise that Python needs a story on mobile platforms, and I'm interested in working on that story. If you go back and read the Python-ideas thread from a few months ago, it looks like there was broad support for the idea, but it would all hinge on the specifics. So, that's what I've been working on. Since I posted to Python-ideas in October, I've been focussing on getting the patches necessary for Python's own build system. However, I've been distracted by work life etc, so I haven't made as much progress as I would have liked. I'm hoping the Christmas/New year break will give me a chance to make some headway. As far as Kivy goes - I have tinkered with Kivy; I've even used Kivy's tools as a starting point for some of my own efforts. However, to me, Kivy is focussing too far up the stack - their toolchain appears to be based on getting *Kivy* working on mobile, not *Python*. This is an entirely reasonable approach if Kivy is what you want at the end of the day - but it's not what *I* want. I've been taking a much more atomic approach. The Kivy toolchain is also anchored in old versions of Python 2; something that definitely needs to be addressed. Ultimately, I want to get these patches in to Python's trunk; but I'm still a way off that being a reality. If you're interested in collaborating and helping me get to that point, please get in touch - there's plenty of work to do, and if you're keen to help, I'm happy to share what I've got so far. Yours, Russ Magee %-) On Fri, Dec 26, 2014 at 6:34 PM, Fetchinson . <fetchinson@googlemail.com> wrote:
Hi all, maybe the best list would be python-dev but I don't dare waking the sleeping lions there :)
So my question is this: is there a coherent mobile strategy among core dev people? I mean you guys release python for linux/macos/windows and the question is if there are any plans to do the same for a mobile platform. It doesn't have to be android or ios just anything that the core dev team chooses and sticks with.
I've been developing python apps for smartphones (mostly hobby projects though) using sl4a but that seems like is dead. Now people suggest me using kivy which seems to be alive but who knows how long. There are some other projects qpython, etc, which are small and equally not so reliable at least looking from the outside. Is kivy now an officially blessed distribution? Since google was so integral to both python (through employing Guido) and android I'd think it would make sense for google to have an official python environment for android in cooperation with the python dev team.
Does the PSF has an opinion on this? It would be great if there would be something for mobile phones that we could rely on not going away just as with linux/macos/windows.
Or there are some issues which preclude this from the start?
Cheers, Daniel
-- Psss, psss, put it down! - http://www.cafepress.com/putitdown _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
On 12/27/14, Russell Keith-Magee <russell@keith-magee.com> wrote:
Hi Daniel,
I've been working on this problem recently; I posted about the idea to this very list a few months ago:
https://mail.python.org/pipermail/python-ideas/2014-October/029856.html
Thanks! This was a great read, I haven't noticed it before. You addressed all the issues (and much more) I thought about. And basically I got all the answers from the follow up posts.
At the time I posted, I had posted Python builds that work on both Android and iOS:
https://github.com/pybee/Python-iOS-support https://github.com/pybee/Python-Android-support
and template projects that get you to "hello world" on a mobile platform without much effort.
https://github.com/pybee/Python-iOS-template https://github.com/pybee/Python-Android-template
Thanks again, I'll take a look, it all seems pretty encouraging.
I've also tackled the cross-language bridging issue:
https://github.com/pybee/rubicon-objc https://github.com/pybee/rubicon-java
and wrapped native widgets up into a cross-platform widget library:
Now - I'm not claiming that these are anywhere near production ready - they're proof of concept at best. However, I completely agree with your original premise that Python needs a story on mobile platforms, and I'm interested in working on that story. If you go back and read the Python-ideas thread from a few months ago, it looks like there was broad support for the idea, but it would all hinge on the specifics.
So, that's what I've been working on. Since I posted to Python-ideas in October, I've been focussing on getting the patches necessary for Python's own build system. However, I've been distracted by work life etc, so I haven't made as much progress as I would have liked. I'm hoping the Christmas/New year break will give me a chance to make some headway.
As far as Kivy goes - I have tinkered with Kivy; I've even used Kivy's tools as a starting point for some of my own efforts. However, to me, Kivy is focussing too far up the stack - their toolchain appears to be based on getting *Kivy* working on mobile, not *Python*.
What do you mean by this exactly? I thought kivy = python + some libraries. So if kivy works on android that necessarily means that python itself works as well, doesn't it? I thought I'd use kivy even if I don't need any of their fancy libraries only a basic python installation, but you'd say this is not a good approach?
This is an entirely reasonable approach if Kivy is what you want at the end of the day - but it's not what *I* want. I've been taking a much more atomic approach. The Kivy toolchain is also anchored in old versions of Python 2; something that definitely needs to be addressed.
As far as I'm concerned python 2 is perfectly okay. If I don't need to worry about python 3, what drawback does kivy have, if any, according to you?
Ultimately, I want to get these patches in to Python's trunk; but I'm still a way off that being a reality. If you're interested in collaborating and helping me get to that point, please get in touch - there's plenty of work to do, and if you're keen to help, I'm happy to share what I've got so far.
I'm afraid I don't have the necessary expertise unfortunately. And I was under the impression kivy will bring me a working python environment on android, but please feel free to set me straight on this one :) Cheers, Daniel
Yours, Russ Magee %-)
On Fri, Dec 26, 2014 at 6:34 PM, Fetchinson . <fetchinson@googlemail.com> wrote:
Hi all, maybe the best list would be python-dev but I don't dare waking the sleeping lions there :)
So my question is this: is there a coherent mobile strategy among core dev people? I mean you guys release python for linux/macos/windows and the question is if there are any plans to do the same for a mobile platform. It doesn't have to be android or ios just anything that the core dev team chooses and sticks with.
I've been developing python apps for smartphones (mostly hobby projects though) using sl4a but that seems like is dead. Now people suggest me using kivy which seems to be alive but who knows how long. There are some other projects qpython, etc, which are small and equally not so reliable at least looking from the outside. Is kivy now an officially blessed distribution? Since google was so integral to both python (through employing Guido) and android I'd think it would make sense for google to have an official python environment for android in cooperation with the python dev team.
Does the PSF has an opinion on this? It would be great if there would be something for mobile phones that we could rely on not going away just as with linux/macos/windows.
Or there are some issues which preclude this from the start?
Cheers, Daniel
-- Psss, psss, put it down! - http://www.cafepress.com/putitdown _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- Psss, psss, put it down! - http://www.cafepress.com/putitdown
On Sun, Dec 28, 2014 at 10:30:41PM +0100, Fetchinson . wrote:
On 12/27/14, Russell Keith-Magee <russell@keith-magee.com> wrote:
This is an entirely reasonable approach if Kivy is what you want at the end of the day - but it's not what *I* want. I've been taking a much more atomic approach. The Kivy toolchain is also anchored in old versions of Python 2; something that definitely needs to be addressed.
I'm not entirely sure why Russell says this. Kivy claims to support Python 3: http://kivy.org/docs/faq.html#does-kivy-support-python-3-x
As far as I'm concerned python 2 is perfectly okay. If I don't need to worry about python 3, what drawback does kivy have, if any, according to you?
Well, you've just lost me as a potential user. I have zero interest in legacy Python versions for Android. -- Steven
On 12/29/14, Steven D'Aprano <steve@pearwood.info> wrote:
On Sun, Dec 28, 2014 at 10:30:41PM +0100, Fetchinson . wrote:
On 12/27/14, Russell Keith-Magee <russell@keith-magee.com> wrote:
This is an entirely reasonable approach if Kivy is what you want at the end of the day - but it's not what *I* want. I've been taking a much more atomic approach. The Kivy toolchain is also anchored in old versions of Python 2; something that definitely needs to be addressed.
I'm not entirely sure why Russell says this. Kivy claims to support Python 3:
http://kivy.org/docs/faq.html#does-kivy-support-python-3-x
As far as I'm concerned python 2 is perfectly okay. If I don't need to worry about python 3, what drawback does kivy have, if any, according to you?
Well, you've just lost me as a potential user. I have zero interest in legacy Python versions for Android.
I sympathize with your approach and I'd probably take the same attitude but so far I'm only using python 2 projects and developing for python 2 only (unfortunately). Cheers, Daniel
-- Steven _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- Psss, psss, put it down! - http://www.cafepress.com/putitdown
Fetchinson . writes:
As far as I'm concerned python 2 is perfectly okay.
Please reconsider this position. For the 70% of the world whose native language does not fit well into ISO 8859-1, apps developed in Python 3 with no consideration for their needs are far more likely to be easily adapted to their environments than those developed in Python 2. If you don't care about the rest of the world, fine, but the rest of the world isn't going to care about you, and that matters to building a Python project given that Indians, Chinese, and a smattering of others account for a large fraction of the "pre-professional" labor we get through GSoC. They tend to be far more focused on mobile apps than their mentors in my experience.
On 12/29/14, Stephen J. Turnbull <stephen@xemacs.org> wrote:
Fetchinson . writes:
As far as I'm concerned python 2 is perfectly okay.
Please reconsider this position. For the 70% of the world whose native language does not fit well into ISO 8859-1, apps developed in Python 3 with no consideration for their needs are far more likely to be easily adapted to their environments than those developed in Python 2.
If you don't care about the rest of the world, fine, but the rest of the world isn't going to care about you, and that matters to building a Python project given that Indians, Chinese, and a smattering of others account for a large fraction of the "pre-professional" labor we get through GSoC. They tend to be far more focused on mobile apps than their mentors in my experience.
I completely understand your point but at this stage I'm only thinking of hobby projects that will probably be used by myself, my wife and our family. Nothing mainstream, google playable, etc. For larger scale projects I'd completely agree with you, python 3 is the way to go. Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown
On Tue, Dec 30, 2014 at 1:19 AM, Fetchinson . <fetchinson@googlemail.com> wrote:
I completely understand your point but at this stage I'm only thinking of hobby projects that will probably be used by myself, my wife and our family. Nothing mainstream, google playable, etc.
For larger scale projects I'd completely agree with you, python 3 is the way to go.
Python 3 isn't just better for large projects. It's better for _every_ project. Just because you think you won't ever need non-ASCII characters doesn't mean you won't ever get any; why not take the easy way out and use Py3? (Case in point: I just sent through a pull request on a project that had a ≤ (U+2264) in a comment. Py2 complained because it used a non-ASCII character and didn't have a coding cookie. Py3 would have accepted it, though sadly it wasn't a Py3-compatible script for other reasons. ASCII simply isn't enough.) ChrisA
Hi! On Tue, Dec 30, 2014 at 01:37:29AM +1100, Chris Angelico <rosuav@gmail.com> wrote:
On Tue, Dec 30, 2014 at 1:19 AM, Fetchinson . <fetchinson@googlemail.com> wrote:
I completely understand your point but at this stage I'm only thinking of hobby projects that will probably be used by myself, my wife and our family. Nothing mainstream, google playable, etc.
For larger scale projects I'd completely agree with you, python 3 is the way to go.
Python 3 isn't just better for large projects. It's better for _every_ project. Just because you think you won't ever need non-ASCII characters doesn't mean you won't ever get any; why not take the easy way out and use Py3? (Case in point: I just sent through a pull request on a project that had a ≤ (U+2264) in a comment. Py2 complained because it used a non-ASCII character and didn't have a coding cookie. Py3 would have accepted it, though sadly it wasn't a Py3-compatible script for other reasons. ASCII simply isn't enough.)
ChrisA
I regularly read and produce programs and texts (and text fields in binary files) in 4 non-ascii encodings -- koi8-r, utf-8, cp1251 and cp866, less frequently in utf-16. Python 2 doesn't stand on my way. Python 3 could be better -- I simple don't know -- but Py2 is still good enough. Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.
I completely understand your point but at this stage I'm only thinking of hobby projects that will probably be used by myself, my wife and our family. Nothing mainstream, google playable, etc.
For larger scale projects I'd completely agree with you, python 3 is the way to go.
Python 3 isn't just better for large projects. It's better for _every_ project. Just because you think you won't ever need non-ASCII characters doesn't mean you won't ever get any; why not take the easy way out and use Py3? (Case in point: I just sent through a pull request on a project that had a ≤ (U+2264) in a comment. Py2 complained because it used a non-ASCII character and didn't have a coding cookie. Py3 would have accepted it, though sadly it wasn't a Py3-compatible script for other reasons. ASCII simply isn't enough.)
I'm not sure I understand you. Are you saying unicode support is not there in python 2? That's certainly not the case. I believe that python 3 is more *convenient* but certainly is not necessary, it's perfectly possible to handle any character set in python 2 as well. Or is there something I'm missing? Cheers, Daniel
ChrisA _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- Psss, psss, put it down! - http://www.cafepress.com/putitdown
On Tue, Dec 30, 2014 at 7:48 AM, Fetchinson . <fetchinson@googlemail.com> wrote:
Python 3 isn't just better for large projects. It's better for _every_ project. Just because you think you won't ever need non-ASCII characters doesn't mean you won't ever get any; why not take the easy way out and use Py3? (Case in point: I just sent through a pull request on a project that had a ≤ (U+2264) in a comment. Py2 complained because it used a non-ASCII character and didn't have a coding cookie. Py3 would have accepted it, though sadly it wasn't a Py3-compatible script for other reasons. ASCII simply isn't enough.)
I'm not sure I understand you. Are you saying unicode support is not there in python 2? That's certainly not the case. I believe that python 3 is more *convenient* but certainly is not necessary, it's perfectly possible to handle any character set in python 2 as well.
You can handle data in any character set using Py2. Explicitly convert to Unicode, work with that, off you go. No problem. You can do that in any language that has encode and decode libraries. The difference is that in Py2, you can forget that you have to encode and decode, and your program will work on ASCII text - and then you'll blame "funny characters" for breaking your program. In Py3, you'll get it right straight off, and it'll work for all of Unicode equally. Plus, Py3 makes the default source code encoding UTF-8 instead of ASCII, so you can have non-ASCII comments without having to slap a coding cookie at the top of the file; and since source code is Unicode text rather than bytes, you can reliably use non-ASCII variable names, module names (I think), and even, with a few tweaks, alternate language keywords. Basically, where Py2 gives you the tools to make a Unicode-aware program, Py3 just makes your program Unicode-aware for you. We're definitely off-topic for python-ideas now. ChrisA
On Mon, Dec 29, 2014 at 5:30 AM, Fetchinson . <fetchinson@googlemail.com> wrote:
On 12/27/14, Russell Keith-Magee <russell@keith-magee.com> wrote:
So, that's what I've been working on. Since I posted to Python-ideas in October, I've been focussing on getting the patches necessary for Python's own build system. However, I've been distracted by work life etc, so I haven't made as much progress as I would have liked. I'm hoping the Christmas/New year break will give me a chance to make some headway.
As far as Kivy goes - I have tinkered with Kivy; I've even used Kivy's tools as a starting point for some of my own efforts. However, to me, Kivy is focussing too far up the stack - their toolchain appears to be based on getting *Kivy* working on mobile, not *Python*.
What do you mean by this exactly? I thought kivy = python + some libraries. So if kivy works on android that necessarily means that python itself works as well, doesn't it?
Yes and no. Yes, Kivy is just a set of Python libraries, and a Kivy program is just a Python program. However, "Hello World" in Kivy isn't 'print("Hello world")'. It's setting up a whole Kivy stack, and starting a Kivy runloop - and the Kivy toolchain is focussed on getting you to the point where you can start that runloop. Even if you work around that, and just use Python "out of the box", you're going to be carrying at least some of the overhead of Kivy.
I thought I'd use kivy even if I don't need any of their fancy libraries only a basic python installation, but you'd say this is not a good approach?
It would probably work - I haven't tried, so I can't comment from experience. However, if you go down this path, you won't have a "Basic python installation" - you'll have "Python + kivy", because their tools don't give you the option to *not* install the Kivy parts (at least, not as far as I could work out).
From my experience, getting Python compiled using Kivy's tools wasn't that hard - but getting Kivy compiled was a PITA, because Kivy has a bunch of other dependencies, like sound support libraries, OpenGL libraries, Cython, and so on. These are all essential for *Kivy*, but not for Python, and not for my purposes either.
Ultimately, I'm working on something that is, at one level, a competitor to Kivy. I don't want my install instructions to be "install Kivy, now throw all that stuff away and use Toga"; and I don't want my users to have to go through the same drama of getting Kivy's whole dependency chain compiled. I *just* want Python, and then I'll decide what other pieces I want. That's why I'm trying to get the build fixes into Python's core - I want *Python* to be compilable for mobile platforms, and then leave the decision of which libraries you want to use up to the end developer. Yours, Russ Magee %-)
On 12/29/14, Russell Keith-Magee <russell@keith-magee.com> wrote:
On Mon, Dec 29, 2014 at 5:30 AM, Fetchinson . <fetchinson@googlemail.com> wrote:
On 12/27/14, Russell Keith-Magee <russell@keith-magee.com> wrote:
So, that's what I've been working on. Since I posted to Python-ideas in October, I've been focussing on getting the patches necessary for Python's own build system. However, I've been distracted by work life etc, so I haven't made as much progress as I would have liked. I'm hoping the Christmas/New year break will give me a chance to make some headway.
As far as Kivy goes - I have tinkered with Kivy; I've even used Kivy's tools as a starting point for some of my own efforts. However, to me, Kivy is focussing too far up the stack - their toolchain appears to be based on getting *Kivy* working on mobile, not *Python*.
What do you mean by this exactly? I thought kivy = python + some libraries. So if kivy works on android that necessarily means that python itself works as well, doesn't it?
Yes and no.
Yes, Kivy is just a set of Python libraries, and a Kivy program is just a Python program.
However, "Hello World" in Kivy isn't 'print("Hello world")'. It's setting up a whole Kivy stack, and starting a Kivy runloop - and the Kivy toolchain is focussed on getting you to the point where you can start that runloop.
Even if you work around that, and just use Python "out of the box", you're going to be carrying at least some of the overhead of Kivy.
Thanks, got it.
I thought I'd use kivy even if I don't need any of their fancy libraries only a basic python installation, but you'd say this is not a good approach?
It would probably work - I haven't tried, so I can't comment from experience. However, if you go down this path, you won't have a "Basic python installation" - you'll have "Python + kivy", because their tools don't give you the option to *not* install the Kivy parts (at least, not as far as I could work out).
From my experience, getting Python compiled using Kivy's tools wasn't that hard - but getting Kivy compiled was a PITA, because Kivy has a bunch of other dependencies, like sound support libraries, OpenGL libraries, Cython, and so on. These are all essential for *Kivy*, but not for Python, and not for my purposes either.
Ultimately, I'm working on something that is, at one level, a competitor to Kivy. I don't want my install instructions to be "install Kivy, now throw all that stuff away and use Toga"; and I don't want my users to have to go through the same drama of getting Kivy's whole dependency chain compiled. I *just* want Python, and then I'll decide what other pieces I want. That's why I'm trying to get the build fixes into Python's core - I want *Python* to be compilable for mobile platforms, and then leave the decision of which libraries you want to use up to the end developer.
Okay, now I understand your project better. And I'd say what I'd like to have is exactly what you are aiming for: having the more or less same python installation as on linux, windows, macos, but this time on android (I don't really care for ios). There is one additional feature I'd like to see though: hardware integration: accessing incoming/outgoing calls, camera, sensors, etc. But I guess that would be a secondary goal, I completely agree with you that first an ordinary python stack would be great. Cheers, Daniel
Yours, Russ Magee %-)
-- Psss, psss, put it down! - http://www.cafepress.com/putitdown
Now - I'm not claiming that these are anywhere near production ready -
On 27 Dec 2014 16:05, "Russell Keith-Magee" <russell@keith-magee.com> wrote: they're proof of concept at best. However, I completely agree with your original premise that Python needs a story on mobile platforms, and I'm interested in working on that story. If you go back and read the Python-ideas thread from a few months ago, it looks like there was broad support for the idea, but it would all hinge on the specifics. Something that doesn't hinge on the specifics: perhaps it would make sense to set up a "mobile-sig@python.org" mailing list? It would presumably be Mailman 2 to start off with, but would then migrate to Mailman 3 & HyperKitty along with the rest of the python.org lists (hopefully some time in 2015, although we don't have a concrete plan for that as yet). Regards, Nick.
On 12/29/14, Nick Coghlan <ncoghlan@gmail.com> wrote:
Now - I'm not claiming that these are anywhere near production ready -
On 27 Dec 2014 16:05, "Russell Keith-Magee" <russell@keith-magee.com> wrote: they're proof of concept at best. However, I completely agree with your original premise that Python needs a story on mobile platforms, and I'm interested in working on that story. If you go back and read the Python-ideas thread from a few months ago, it looks like there was broad support for the idea, but it would all hinge on the specifics.
Something that doesn't hinge on the specifics: perhaps it would make sense to set up a "mobile-sig@python.org" mailing list?
That would be a great idea. It would be a place to point to if other people ask the same question and it would send a signal that the developers are serious about this platform (at least to the extent of setting up a mailing list which is a good start already). Cheers, Daniel
It would presumably be Mailman 2 to start off with, but would then migrate to Mailman 3 & HyperKitty along with the rest of the python.org lists (hopefully some time in 2015, although we don't have a concrete plan for that as yet).
Regards, Nick.
-- Psss, psss, put it down! - http://www.cafepress.com/putitdown
On Mon, Dec 29, 2014 at 6:32 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
Now - I'm not claiming that these are anywhere near production ready -
On 27 Dec 2014 16:05, "Russell Keith-Magee" <russell@keith-magee.com> wrote: they're proof of concept at best. However, I completely agree with your original premise that Python needs a story on mobile platforms, and I'm interested in working on that story. If you go back and read the Python-ideas thread from a few months ago, it looks like there was broad support for the idea, but it would all hinge on the specifics.
Something that doesn't hinge on the specifics: perhaps it would make sense to set up a "mobile-sig@python.org" mailing list?
It would presumably be Mailman 2 to start off with, but would then migrate to Mailman 3 & HyperKitty along with the rest of the python.org lists (hopefully some time in 2015, although we don't have a concrete plan for that as yet).
Sure - if it's not too much effort to establish. I'm not sure exactly what would be discussed there, especially in the short term when the big ticket item is getting the patches into the main Python tree. However, mobile is a significant platform these days, and it can't hurt to have a place where the various players can co-ordinate and collaborate where possible. Yours, Russ Magee %-)
Something that doesn't hinge on the specifics: perhaps it would make sense to set up a "mobile-sig@python.org" mailing list?
It would presumably be Mailman 2 to start off with, but would then migrate to Mailman 3 & HyperKitty along with the rest of the python.org lists (hopefully some time in 2015, although we don't have a concrete plan for that as yet).
Sure - if it's not too much effort to establish.
I'm not sure exactly what would be discussed there, especially in the short term when the big ticket item is getting the patches into the main Python tree.
I'd think the core devs would be far more likely to include a patch if it comes with a big red note on it saying "it was discussed on mobile-sig and was blessed by all participants" as opposed to a random patch by a random person. Cheers, Daniel
However, mobile is a significant platform these days, and it can't hurt to have a place where the various players can co-ordinate and collaborate where possible.
Yours, Russ Magee %-)
-- Psss, psss, put it down! - http://www.cafepress.com/putitdown
Fetchinson . writes:
I'm not sure exactly what would be discussed [on mobile-sig], especially in the short term when the big ticket item is getting the patches into the main Python tree.
It probably matters more that there *is* substantive discussion than *what* is discussed. There are probably a lot of people who are far more interested in "how to do 'it' *now*" than "get 'it' into the main Python tree 'someday'", for example.
I'd think the core devs would be far more likely to include a patch if it comes with a big red note on it saying "it was discussed on mobile-sig and was blessed by all participants" as opposed to a random patch by a random person.
Nope. It helps somewhat to have consensus backing for a particular patch by the (random) interested parties, but not that much. What helps a lot is to get someone trusted to have a good sense for "Pythonicity" and known to have experience in getting patches committed as spokesman. IIUC correctly it is Russ's opinion that his set of patches is not very invasive and wouldn't fall afoul of disturbing some other applications or platforms. If so, the real problem is to get core attention. Although it's a couple of months off, I would suggest a talk (if it's still possible to schedule), a BOF, and a sprint at Pycon North America in March. That should get things moving, and several of the "important" folks who have already expressed interest should be there, too. Regards,
On Wed, Dec 31, 2014 at 11:16 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
Fetchinson . writes:
I'm not sure exactly what would be discussed [on mobile-sig], especially in the short term when the big ticket item is getting the patches into the main Python tree.
It probably matters more that there *is* substantive discussion than *what* is discussed. There are probably a lot of people who are far more interested in "how to do 'it' *now*" than "get 'it' into the main Python tree 'someday'", for example.
I'm not sure if a mailing list would help with this as much as a good, simple set of docs. It's not like there's unknown territory here; once you've got Python installed on a mobile device, the "how" is reasonably easy. The catch is that someone with Python experience won't necessarily have experience managing a cross-platform C/Automake build, which is what you need to get Python installed in the first place. However, once someone provides a binary for Python, others can just use that binary. That's what I've done with my platform support libraries and templates; they're a set of step-by-step instructions for going from a clean sheet to a running Python install. Again, I'm not claiming my code is complete and production ready - just that this is an achievable goal IMHO, and my intention is to document "getting Python working" independent of getting any particular platform working. To my mind, while this *could* be maintained as an external set of patches etc, it makes sense to get the patches into the main source tree.
I'd think the core devs would be far more likely to include a patch
if it comes with a big red note on it saying "it was discussed on mobile-sig and was blessed by all participants" as opposed to a random patch by a random person.
Nope. It helps somewhat to have consensus backing for a particular patch by the (random) interested parties, but not that much. What helps a lot is to get someone trusted to have a good sense for "Pythonicity" and known to have experience in getting patches committed as spokesman.
IIUC correctly it is Russ's opinion that his set of patches is not very invasive and wouldn't fall afoul of disturbing some other applications or platforms. If so, the real problem is to get core attention.
That is correct. There are a couple of tweaks needed to improve cross platform build support, a couple of tweaks introducing sys.platform support for iOS and Android, and some other miscellaneous patches to correct support for individual features. There's a bunch of little changes required, but it's not a big patch by any measure. Although it's a couple of months off, I would suggest a talk (if it's
still possible to schedule), a BOF, and a sprint at Pycon North America in March. That should get things moving, and several of the "important" folks who have already expressed interest should be there, too.
Unfortunately, due to the tyranny of distance (I'm based on the west coast of Australia), plus work commitments, it's unlikely that I'll be attending PyCon in Montreal. Yours, Russ Magee %-)
On 31 December 2014 at 13:42, Russell Keith-Magee <russell@keith-magee.com> wrote:
On Wed, Dec 31, 2014 at 11:16 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
Fetchinson . writes:
I'm not sure exactly what would be discussed [on mobile-sig], especially in the short term when the big ticket item is getting the patches into the main Python tree.
It probably matters more that there *is* substantive discussion than *what* is discussed. There are probably a lot of people who are far more interested in "how to do 'it' *now*" than "get 'it' into the main Python tree 'someday'", for example.
I'm not sure if a mailing list would help with this as much as a good, simple set of docs. It's not like there's unknown territory here; once you've got Python installed on a mobile device, the "how" is reasonably easy. The catch is that someone with Python experience won't necessarily have experience managing a cross-platform C/Automake build, which is what you need to get Python installed in the first place.
One of the benefits of a SIG over python-ideas is that their remit can be broader than just CPython. distutils-sig is probably the most expansive on that front, but As far as setting one up goes, I believe the page at https://www.python.org/community/sigs/guidelines/ is still accurate (although the blurb isn't quite right when it comes to long lived topical sigs like distutils-sig, or intermittently active sigs like import-sig) Although it's a couple of months off, I would suggest a talk (if it's
still possible to schedule), a BOF, and a sprint at Pycon North America in March. That should get things moving, and several of the "important" folks who have already expressed interest should be there, too.
Unfortunately, due to the tyranny of distance (I'm based on the west coast of Australia), plus work commitments, it's unlikely that I'll be attending PyCon in Montreal.
Will you be at LCA this year? At the very least we can continue the various discussions from PyCon AU :) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Fri, Jan 2, 2015 at 6:40 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 31 December 2014 at 13:42, Russell Keith-Magee <russell@keith-magee.com> wrote:
On Wed, Dec 31, 2014 at 11:16 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
Fetchinson . writes:
I'm not sure exactly what would be discussed [on mobile-sig], especially in the short term when the big ticket item is getting the patches into the main Python tree.
It probably matters more that there *is* substantive discussion than *what* is discussed. There are probably a lot of people who are far more interested in "how to do 'it' *now*" than "get 'it' into the main Python tree 'someday'", for example.
I'm not sure if a mailing list would help with this as much as a good, simple set of docs. It's not like there's unknown territory here; once you've got Python installed on a mobile device, the "how" is reasonably easy. The catch is that someone with Python experience won't necessarily have experience managing a cross-platform C/Automake build, which is what you need to get Python installed in the first place.
One of the benefits of a SIG over python-ideas is that their remit can be broader than just CPython.
I'd like to see a mobile-sig, because I think there's enough to discuss that isn't relevant to -dev. I plan to get IronPython running on Xamarin Android/iOS sometime this year so it would be helpful to coordinate things with CPython and Jython - for example, what the values will be for things like sys.platform and os.name will be, and issues around file system emulation, supported modules, etc. that should be compatible for all implementations. Plus there's the issue of new libraries for sensors, GPS, cameras, etc. that provide Pythonic wrappers over the platform APIs. It's not just "get CPython working on mobile" but "how should Python look & feel on mobile devices". (Of course, CPython is special so it's implementation details are still fair game.) So +1 on mobile-sig from me. I'll even volunteer to get it set up & administer it, if no one else is dying to. - Jeff
I'd like to see a mobile-sig, because I think there's enough to discuss that isn't relevant to -dev. I plan to get IronPython running on Xamarin Android/iOS sometime this year so it would be helpful to coordinate things with CPython and Jython - for example, what the values will be for things like sys.platform and os.name will be, and issues around file system emulation, supported modules, etc. that should be compatible for all implementations.
Plus there's the issue of new libraries for sensors, GPS, cameras, etc. that provide Pythonic wrappers over the platform APIs. It's not just "get CPython working on mobile" but "how should Python look & feel on mobile devices". (Of course, CPython is special so it's implementation details are still fair game.)
So +1 on mobile-sig from me. I'll even volunteer to get it set up & administer it
+1 -- Psss, psss, put it down! - http://www.cafepress.com/putitdown
On Mon, Jan 5, 2015 at 4:28 PM, Fetchinson . <fetchinson@googlemail.com> wrote:
So +1 on mobile-sig from me. I'll even volunteer to get it set up & administer it
+1
Apologies for the delay. I've sent a request to meta-sig to create mobile-sig. Anyone interested should chime in over there (https://mail.python.org/mailman/listinfo/meta-sig). - Jeff
On 1/12/15, Jeff Hardy <jdhardy@gmail.com> wrote:
On Mon, Jan 5, 2015 at 4:28 PM, Fetchinson . <fetchinson@googlemail.com> wrote:
So +1 on mobile-sig from me. I'll even volunteer to get it set up & administer it
+1
Apologies for the delay. I've sent a request to meta-sig to create mobile-sig. Anyone interested should chime in over there (https://mail.python.org/mailman/listinfo/meta-sig).
The new mobile-sig mailing list is alive: https://mail.python.org/pipermail/mobile-sig/2015-January/thread.html Thanks a lot to our postmaster! Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown
Lots of great links in this thread: It could be useful to update the Android wiki page * https://wiki.python.org/moin/Android # I had started an awesome-python-android/README.rst on GitHub, # but I think I might've pushed over it and now cannot find it. On Sat, Dec 27, 2014 at 12:04 AM, Russell Keith-Magee < russell@keith-magee.com> wrote:
Hi Daniel,
I've been working on this problem recently; I posted about the idea to this very list a few months ago:
https://mail.python.org/pipermail/python-ideas/2014-October/029856.html
At the time I posted, I had posted Python builds that work on both Android and iOS:
https://github.com/pybee/Python-iOS-support https://github.com/pybee/Python-Android-support
and template projects that get you to "hello world" on a mobile platform without much effort.
https://github.com/pybee/Python-iOS-template https://github.com/pybee/Python-Android-template
I've also tackled the cross-language bridging issue:
https://github.com/pybee/rubicon-objc https://github.com/pybee/rubicon-java
and wrapped native widgets up into a cross-platform widget library:
Now - I'm not claiming that these are anywhere near production ready - they're proof of concept at best. However, I completely agree with your original premise that Python needs a story on mobile platforms, and I'm interested in working on that story. If you go back and read the Python-ideas thread from a few months ago, it looks like there was broad support for the idea, but it would all hinge on the specifics.
So, that's what I've been working on. Since I posted to Python-ideas in October, I've been focussing on getting the patches necessary for Python's own build system. However, I've been distracted by work life etc, so I haven't made as much progress as I would have liked. I'm hoping the Christmas/New year break will give me a chance to make some headway.
As far as Kivy goes - I have tinkered with Kivy; I've even used Kivy's tools as a starting point for some of my own efforts. However, to me, Kivy is focussing too far up the stack - their toolchain appears to be based on getting *Kivy* working on mobile, not *Python*. This is an entirely reasonable approach if Kivy is what you want at the end of the day - but it's not what *I* want. I've been taking a much more atomic approach. The Kivy toolchain is also anchored in old versions of Python 2; something that definitely needs to be addressed.
Ultimately, I want to get these patches in to Python's trunk; but I'm still a way off that being a reality. If you're interested in collaborating and helping me get to that point, please get in touch - there's plenty of work to do, and if you're keen to help, I'm happy to share what I've got so far.
Yours, Russ Magee %-)
On Fri, Dec 26, 2014 at 6:34 PM, Fetchinson . <fetchinson@googlemail.com> wrote:
Hi all, maybe the best list would be python-dev but I don't dare waking the sleeping lions there :)
So my question is this: is there a coherent mobile strategy among core dev people? I mean you guys release python for linux/macos/windows and the question is if there are any plans to do the same for a mobile platform. It doesn't have to be android or ios just anything that the core dev team chooses and sticks with.
I've been developing python apps for smartphones (mostly hobby projects though) using sl4a but that seems like is dead. Now people suggest me using kivy which seems to be alive but who knows how long. There are some other projects qpython, etc, which are small and equally not so reliable at least looking from the outside. Is kivy now an officially blessed distribution? Since google was so integral to both python (through employing Guido) and android I'd think it would make sense for google to have an official python environment for android in cooperation with the python dev team.
Does the PSF has an opinion on this? It would be great if there would be something for mobile phones that we could rely on not going away just as with linux/macos/windows.
Or there are some issues which preclude this from the start?
Cheers, Daniel
-- Psss, psss, put it down! - http://www.cafepress.com/putitdown _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
On Mon, Dec 29, 2014 at 10:39 PM, Wes Turner <wes.turner@gmail.com> wrote:
As far as Kivy goes - I have tinkered with Kivy; I've even used Kivy's tools as a starting point for some of my own efforts. However, to me, Kivy is focussing too far up the stack - their toolchain appears to be based on getting *Kivy* working on mobile, not *Python*. This is an entirely reasonable approach if Kivy is what you want at the end of the day - but it's not what *I* want. I've been taking a much more atomic approach. The Kivy toolchain is also anchored in old versions of Python 2; something that definitely needs to be addressed.
IIUC, how Kivy works is not to put a python interpreter on the platform, but rather to run all your code through Cython, creating a C program that used the python runtime as a library, essentially. So there is no python code involved at run time. So the Kivy lib aside, is this a good way to go on Mobile? I can't image it's too hard to remove the kivy UI stuff if you don't want to use it -- even if the current tools all include all that by default. 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.? Something to keep in mind is that that way most Python code is run may not make sense (or even be an option with Apple's rules, anyway): you have a python environment installed, and install a bunch of application code on top of that, and run that. Makes sense to system scripts, and web apps and that like, but really doesn't make sense for "Apps". What I'm getting at is that the final goal for what exactly we want people to be be able to distribute may effect decisions about what to build and how to build it. BTW, one thing I'd like to be able to build is what I call a "BILS" (Browser Interface, Local Server) app: you run a web server bundled up in an app that points itself to the browser component for all the UI. We've been very successful doing this on Windows and OS-X, as a way to provide a self contained desktop app, and a hosted Web App with almost entirely one code base, and an identical user interface. (http://cameochemicals.noaa.gov/ and http://response.restoration.noaa.gov/cameochemicals) (Python / Pyramid on the back end, desktop is the local browser hosted by a wxPython wrapper) We'd like to be able to port that to iOS and Android, but there doesn't appear to be a solid python option that we could run a Pyramid web server on Mobile at this point -- maybe I'm wrong) -Chris -- Christopher Barker, Ph.D. Oceanographer 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@noaa.gov
On Tue, Dec 30, 2014 at 1058, Chris Barker chris.barker@noaa.gov wrote:
BTW, one thing I'd like to be able to build is what I call a "BILS" (Browser Interface, Local Server) app: you run a web server bundled up in an app that points itself to the browser component for all the UI. We've been very successful doing this on Windows and OS-X, as a way to provide a self contained desktop app, and a hosted Web App with almost entirely one code base, and an identical user interface.
(http://cameochemicals.noaa.gov/ and http://response.restoration.noaa.gov/cameochemicals)
(Python / Pyramid on the back end, desktop is the local browser hosted by a wxPython wrapper)
We'd like to be able to port that to iOS and Android, but there doesn't appear to be a solid python option that we could run a Pyramid web server on Mobile at this point -- maybe I'm wrong)
This is what I've been trying to do as well, for Android. I'm particularly interested in running an iPython server connected to the local Android browser. For iPad there is an example of someone having achieved exactly this: http://computableapp.com/. But I don't know if they've actually made any of their porting knowledge public. For Android I've been focusing on submitting patches to CPython 3.4/3.5 for things that can be argued to be "just cross-compilation bugs" in the Cpython source. For example: http://bugs.python.org/issue21668 just fixes a missing -lm flag during compilation (that doesn't matter on Linux/MacOS/Windows, but is technically required, and causes problems with the Android dynamic loader if it is missing). http://bugs.python.org/issue20306 just takes care of the fact that pw_gecos isn't actually required by Posix. -Matt
On Wed, Dec 31, 2014 at 4:10 AM, Frank, Matthew I <matthew.i.frank@intel.com
wrote:
For Android I've been focusing on submitting patches to CPython 3.4/3.5 for things that can be argued to be "just cross-compilation bugs" in the Cpython source.
For example: http://bugs.python.org/issue21668 just fixes a missing -lm flag during compilation (that doesn't matter on Linux/MacOS/Windows, but is technically required, and causes problems with the Android dynamic loader if it is missing).
http://bugs.python.org/issue20306 just takes care of the fact that pw_gecos isn't actually required by Posix.
Thanks for the heads up - I'll keep an eye on those tickets. And, if you're interested in collaborating on getting the rest of the compilation steps working on Android, let me know. Yours, Russ Magee %-)
On Wed, Dec 31, 2014 at 12:58 AM, Chris Barker <chris.barker@noaa.gov> wrote:
On Mon, Dec 29, 2014 at 10:39 PM, Wes Turner <wes.turner@gmail.com> wrote:
As far as Kivy goes - I have tinkered with Kivy; I've even used Kivy's tools as a starting point for some of my own efforts. However, to me, Kivy is focussing too far up the stack - their toolchain appears to be based on getting *Kivy* working on mobile, not *Python*. This is an entirely reasonable approach if Kivy is what you want at the end of the day - but it's not what *I* want. I've been taking a much more atomic approach. The Kivy toolchain is also anchored in old versions of Python 2; something that definitely needs to be addressed.
IIUC, how Kivy works is not to put a python interpreter on the platform, but rather to run all your code through Cython, creating a C program that used the python runtime as a library, essentially. So there is no python code involved at run time.
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. Toga/Rubicon takes a similar approach, but using ctypes directly, instead of using Cython.
So the Kivy lib aside, is this a good way to go on Mobile? I can't image it's too hard to remove the kivy UI stuff if you don't want to use it -- even if the current tools all include all that by default.
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). 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 optimisations - you still need to have all the language bindings etc. On top of that, on Android, the end product must essentially be a JAR file. Jython doesn't currently work on the Dalvik VM, so there's a whole other level of tooling required. This might be changing with Android 5/Lollipop - I've only had a brief look at the VM changed in Android 5.
Something to keep in mind is that that way most Python code is run may not make sense (or even be an option with Apple's rules, anyway): you have a python environment installed, and install a bunch of application code on top of that, and run that. Makes sense to system scripts, and web apps and that like, but really doesn't make sense for "Apps".
What I'm getting at is that the final goal for what exactly we want people to be be able to distribute may effect decisions about what to build and how to build it.
However, at the core, an "app" is just iOS/Android are running a process. Just as on desktop or web, that process can, if you so choose, start a Python interpreter and run a script. It's just a set of instructions. Yes, those instructions need to play nice with your local platform conditions, but that's no different to the distinction between desktop apps and web apps - I've spent plenty of time on the Django-users mailing list teaching newcomers to the web that you can't just take a long lived process and treat a web request as a button click starting that process - you need to restructure your code to take into account the short lived, stateless nature of HTTP requests. 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 (i.e., you can't deliver updates/enhancements by sending an installed app a new script to run). There are Kivy apps in the App Store right now. Of course, this is subject to the whims and fancies of Apple, but this has been a stable policy for a couple of years, and I suspect there would be a riot if this policy were to change substantially, because it's central to the operation of many games engines. BTW, one thing I'd like to be able to build is what I call a "BILS"
(Browser Interface, Local Server) app: you run a web server bundled up in an app that points itself to the browser component for all the UI. We've been very successful doing this on Windows and OS-X, as a way to provide a self contained desktop app, and a hosted Web App with almost entirely one code base, and an identical user interface.
(http://cameochemicals.noaa.gov/ and http://response.restoration.noaa.gov/cameochemicals)
(Python / Pyramid on the back end, desktop is the local browser hosted by a wxPython wrapper)
We'd like to be able to port that to iOS and Android, but there doesn't appear to be a solid python option that we could run a Pyramid web server on Mobile at this point -- maybe I'm wrong)
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. Yours, Russ Magee %-)
On Tue, Dec 30, 2014 at 5:34 PM, Russell Keith-Magee < russell@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! -Chris -- Christopher Barker, Ph.D. Oceanographer 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@noaa.gov
participants (14)
-
Andrew Barnert -
Chris Angelico -
Chris Barker -
Ethan Furman -
Fetchinson . -
Frank, Matthew I -
Jeff Hardy -
Nick Coghlan -
Oleg Broytman -
Russell Keith-Magee -
Stephen J. Turnbull -
Steven D'Aprano -
Sturla Molden -
Wes Turner