One limitation we didn't work around yet with pyjnius, and that is quite painful on android, is that JNI doesn't provide a way to extend a class, and it's painful because a lot of the android API requires you to do precisely that, in such case the way to do it is to do a java class for the part that requires it, and then use this class from pyjnius, but it's not very nice to have to jump to java often if you use a lot of the android api that requires that. Another way I toyed with (quite some time ago) was to automatically generate utility classes, that allowed you to implement an interface instead of extending a class (the generated java class would call code from your implementation in its overriden methods), but failing to find a way to generate a whole set of the possible classes you'd need to generate the android api, i put that aside and never really came back to it. Another possible solution was suggested recently, which was using bytebuddy [1] to generate the classes you'd need, i didn't explore this track, since i'm not currently focused on android stuff, but that could be a nice way to work around the issue.

[1] http://bytebuddy.net/

@david: thanks for sharing, that does look nice, and as was said, even parts of it could maybe help us to do a better usage of android assets formats, so thanks again for sharing :)

On Tue, May 17, 2016 at 07:18:01PM +0200, Dima Tisnek wrote:
How about python-java bridge, like Rubicon or pyjnius?

You get best of both worlds -- a good language and a mature runtime.
On 17 May 2016 18:05, "David Boddie" <[email protected]> wrote:

In a belated attempt to jump on the Android bandwagon I started to look
into learning Java and the Android APIs. I realised very quickly that I
couldn't face writing a lot of code in that language. Looking around for
other languages running on the Dalvik VM, I found a few that might be nicer
than Java, but I wasn't so sure that I wanted to write in any of those,
either.

In the end, I decided to try an experiment to see how much I could learn
about Dalvik and Java by creating tools to handle some of the file formats
used in Android packaging, and by trying to implement a compiler for a
subset
of Python.

The result can be found in this repository:

 https://bitbucket.org/dboddie/duck

It should be noted that the source language isn't really Python. The parser
from the standard library is used to parse it, but the semantics of the
generated code are different to those of Python. That's why I gave the
language a different name.

How is this relevant to a mailing list about Python on mobile platforms?

Firstly, the language may be close enough to Python for people to find it
more familiar than Java, even if there are places where the differences may
trip them up. Writing code to fit into a framework designed for a statically
typed language requires a slightly different mindset to the one you might
have when writing regular Python code, so it may not seem so strange to
developers once they've accepted that.

Secondly, it makes it possible to write a more faithful implementation of
Python using code that looks a lot like Python, instead of Java. You could
use it to write support code for a compiler, or perhaps write an interpreter
in it.

It's all very experimental at the moment. I've been uncomfortable about
publishing it before now because I keep finding things I've overlooked,
though it's been a good learning experience. Maybe there will be things in
there that people find useful.

David
_______________________________________________
Mobile-sig mailing list
[email protected]
https://mail.python.org/mailman/listinfo/mobile-sig

_______________________________________________
Mobile-sig mailing list
[email protected]
https://mail.python.org/mailman/listinfo/mobile-sig

Attachment: signature.asc
Description: PGP signature

_______________________________________________
Mobile-sig mailing list
[email protected]
https://mail.python.org/mailman/listinfo/mobile-sig

Reply via email to