Calling (C)Python code from Java: Is it JPype?

[F. GEIGER]

I've dev'ed a Python prototype of an app, that besides the internals making
it up has a gui. While test-driven dev'ing the app's internals in Python is
fun as usual, dev'ing the GUI is not so funny, at least for me.

I guess dev'ing a GUI in a test-driven way is not possible, or is it? I'm
using wxPython, so if anyone has an idea...

For now most of the time I extend and change the gui things, then run it, do
the clicks to go thru the new things and - bang: Missing attribute bla bla
bla or an error like that. Yes, I use Pychecker, but it isn't of real help
in gui dev'ing (at least in my GUIs ;-)).

So, a compiler could ease things a bit here. While I want the complicated
stuff remaining written in Python, I'd write the GUI things in Java. Java,
because I plan to run the app on Linux too (dev'ing on Windows for now).
Otherwise *.NET could be an option (well, perhaps I should look at Mono).

Now, if I go the Java route, how can I call my Python stuff from Java, if I
do not want to use Jython, which lags behind CPython 3 minor versions (2.1.
vs. 2.4)? Google showed up JPype, but this seems to enable me the other way
round: Call Java code from CPython. Or are there any plans to make this
possible the other way round too?

Any other options here?

Many thanks in advance
Franz GEIGER

[Steve Menard]

F. GEIGER wrote:

I've dev'ed a Python prototype of an app, that besides the internals making
it up has a gui. While test-driven dev'ing the app's internals in Python is
fun as usual, dev'ing the GUI is not so funny, at least for me.

I guess dev'ing a GUI in a test-driven way is not possible, or is it? I'm
using wxPython, so if anyone has an idea...

For now most of the time I extend and change the gui things, then run it, do
the clicks to go thru the new things and - bang: Missing attribute bla bla
bla or an error like that. Yes, I use Pychecker, but it isn't of real help
in gui dev'ing (at least in my GUIs ;-)).

So, a compiler could ease things a bit here. While I want the complicated
stuff remaining written in Python, I'd write the GUI things in Java. Java,
because I plan to run the app on Linux too (dev'ing on Windows for now).
Otherwise *.NET could be an option (well, perhaps I should look at Mono).

Now, if I go the Java route, how can I call my Python stuff from Java, if I
do not want to use Jython, which lags behind CPython 3 minor versions (2.1.
vs. 2.4)? Google showed up JPype, but this seems to enable me the other way
round: Call Java code from CPython. Or are there any plans to make this
possible the other way round too?

Any other options here?

Many thanks in advance
Franz GEIGER

Well, lemme see how you can have you cake and eat it too :)

Right now, JPype does not allow you to call Python code "as is".
Besides, adaptic a static language like java to a dynamic language like
python is "easy". Going the other way is ... impossible.

What JPype allows you to do is use Java classes as though they were
regular Python classes. This includes Standard java classes as well as
classes you've written youself.

Somewhere in the back of my head there are plans to make python classes
available to Java. The goal though wil be to be able to make use of the
many frameworks availabel in the Java worlds, be it server technologies
like servlets and EJBs, or client-side stuff like Eclipse.

Aside form that, your problem is exactly one of the problems that
incited me to write JPype. Python GUI toolkits just seem, to my
java-trained mind, too hard to use.

So, what I would do is have Python be the "host", the controller,
calling the JAVA-built GUI and registering listeners. JPype does not
allow subclassing of Java classes in python, but you can crerate JProxy
that "implement" any Java interface. The standard idiom for Java event
and callbacks is based on the use of interfaces anyway. In fact, baring
the very rare cases where Swing requires subclasses, you could crerate
your whole GUI using Swing and not writing a single line of Java.

Hopefully this answers your question. IF you have any, feel free to
contact me through sourceforge.

Steve

[F. GEIGER]

"Steve Menard" <fo*@bar.com> schrieb im Newsbeitrag
news:1D*****************@weber.videotron.net...

<snip/>

So, what I would do is have Python be the "host", the controller,
calling the JAVA-built GUI and registering listeners. JPype does not
allow subclassing of Java classes in python, but you can crerate JProxy
that "implement" any Java interface. The standard idiom for Java event
and callbacks is based on the use of interfaces anyway. In fact, baring
the very rare cases where Swing requires subclasses, you could crerate
your whole GUI using Swing and not writing a single line of Java.
Just to be sure that I got you right: I'd write the GUI things in Java and
hook the Python stuff into the GUI by implementing listeners directly or by
implementing interfaces used by the listeners in Python (sorry, yet I'm not
very experienced in Java). For me this sounds like what I want to have: The
GUI in a compiled lang, the gist in Python. If so, I'll give it a try.

Steve

Many thanks, Steve!

Cheers
Franz

[Ville Vainio]

>>>>> "f.geiger" == F GEIGER <f.******@vol.at> writes:
f.geiger> GUI in a compiled lang, the gist in Python. If so, I'll give it a try.

Why GUI in compiled lang? Typically the time in a GUI is spent in a
GUI library, which is native code.

--
Ville Vainio http://tinyurl.com/2prnb

[F. GEIGER]

"Ville Vainio" <vi***@spammers.com> schrieb im Newsbeitrag
news:du*************@lehtori.cc.tut.fi...

>> "f.geiger" == F GEIGER <f.******@vol.at> writes:

f.geiger> GUI in a compiled lang, the gist in Python. If so, I'll give

it a try.
Why GUI in compiled lang? Typically the time in a GUI is spent in a
GUI library, which is native code.
It is not because of the performance. I never had any problems with Python
in this regard. It is because pychecker does not catch all errors *I* make
in *my* GUI programs (YMMV of course). Errors, a compiler typically is able
to catch. It gets really annoying if I aways have to do all the steps again
and again getting to the point the *GUI* part of my app just to see that I
again had missed something. I am willing to give up on flexibilty in the
*GUI* part of my app to receive type safety and in consequence compile time
error checking.

If anyone could show me a way how I can develop the *GUI* part of may apps
in a test driven way, i.e. w/o having to enter data manually all over again,
then I could forget about all this.

Many thanks and kind regards
Franz GEIGER

P.S.: Ville, perhaps you answered to my post because I'd like it to have the
other way round: GUI stuff a compiled lang (but not C++ if possible) and the
gist, which many times is considered time critical by other people, in
Python. But, as I said: I never had performance problems with Python. Python
speeds up dev'ing apps and *app-specific* things because it lets me think
mostly in the problem domain and not in the lang domain. Ever handled
strings, lists etc. in C++ or Java? Forget it! Well, ok, I have to admit:
I'm a Java newbie, yet, and thus I am not allowed yet to rant, actually. But
you got the point: So many things are just easy to do in Python and I don't
want to give up on *that*. OTOH: GUI stuff mostly is a SMOP, nothing special
(possiblities in wx are great, though. I can do things here, I couldn't
dream of doing it in, say, VB). Here a compiler really could make things
easier - for *me* and *my* apps. Again, YMMV.

--
Ville Vainio http://tinyurl.com/2prnb

[Neil Benn]

Ville Vainio wrote:

>>"f.geiger" == F GEIGER <f.******@vol.at> writes:
>>
>>

f.geiger> GUI in a compiled lang, the gist in Python. If so, I'll give it a try.

Why GUI in compiled lang? Typically the time in a GUI is spent in a
GUI library, which is native code.

Hello,

As I remember, the OP said that he was going to use Java - the
GUI toolkit for that is very nice and extremely portable (no cross
platform niggling little issues 'the window doesn't behave that way on
linux - well it does on windows!!') - the reason for this - Java GUI
(Swing ignore AWT for the point of this - AWT has the same problems as
other native GUI toolkits) is _not_ native. Although I must agree that
using cross language and two separate processes seems like more of a
headache that testing the python code.

Cheers,

Neil

--

Neil Benn
Senior Automation Engineer
Cenix BioScience
BioInnovations Zentrum
Tatzberg 47
D-01307
Dresden
Germany

Tel : [phone]
e-mail : be**@cenix-bioscience.com
Cenix Website : http://www.cenix-bioscience.com

[Cameron Laird]

In article <ma**************************************@python.o rg>,
Neil Benn <be**@cenix-bioscience.com> wrote:

[Cameron Laird]

In article <cj**********@newshispeed.ch>, F. GEIGER <f.******@vol.at> wrote:

[Ville Vainio]

>>>>> "geiger" == F GEIGER <f.******@vol.at> writes:

Why GUI in compiled lang? Typically the time in a GUI is spent in a
GUI library, which is native code.

geiger> It is not because of the performance. I never had any

Ok - just checking. "Compiled language" is so widely abused term,
typically used in the context of performance. You were looking for the
term "statically typed language".

geiger> again had missed something. I am willing to give up on
geiger> flexibilty in the *GUI* part of my app to receive type
geiger> safety and in consequence compile time error checking.

I'm not big on GUI programming, but for me the problem with GUIs, that
a statically typed language would help you catch, is the large amount
of different methods taking a large variety of parameters. You only
need to get them right once, different data sets don't create too many
different situations that would break the GUI. Or at least those parts
that would be helped by static typing.

geiger> If anyone could show me a way how I can develop the *GUI*
geiger> part of may apps in a test driven way, i.e. w/o having to
geiger> enter data manually all over again, then I could forget
geiger> about all this.

Is the UI complex? With simple UIs, the part that needs to interface
with the actual UI library is trivial, and generally not worth unit
testing. TDD the "model"/"document" part of the UI. Or just hack
together some kind of simple UI that you can use to test / demo your
app, and put up the time to create a more sophisticated UI that you
test thoroughly when the rest of the stuff works.

geiger> mostly in the problem domain and not in the lang
geiger> domain. Ever handled strings, lists etc. in C++ or Java?

Have I ever!

HBufC* concat_stringsL(const TDesC& aS1, const TDesC& aS2)
{
HBufR* res = HBufC::NewLC(aS1.Length() + aS2.Length());
res->Des() = aS1;
res->Des().Append(aS2);
return res;
}

geiger> you got the point: So many things are just easy to do in
geiger> Python and I don't want to give up on *that*. OTOH: GUI
geiger> stuff mostly is a SMOP, nothing special (possiblities in
geiger> wx are great, though. I can do things here, I couldn't
geiger> dream of doing it in, say, VB). Here a compiler really
geiger> could make things easier - for *me* and *my* apps. Again,
geiger> YMMV.

It can make things easier, but the cross-language interface (esp. as
it's a custom one, not a polished one like, say, wxPython is for
wxWindows/C++) can offset the easiness.

--
Ville Vainio http://tinyurl.com/2prnb

[Neil Benn]

cl****@lairds.us (Cameron Laird) wrote in message news:<si************@lairds.us>...

In article <ma**************************************@python.o rg>,
Neil Benn <be**@cenix-bioscience.com> wrote:
.
.
.

As I remember, the OP said that he was going to use Java - the
GUI toolkit for that is very nice and extremely portable (no cross
platform niggling little issues 'the window doesn't behave that way on
linux - well it does on windows!!') - the reason for this - Java GUI
(Swing ignore AWT for the point of this - AWT has the same problems as
other native GUI toolkits) is _not_ native. Although I must agree that .
.

Hello,

Comments embedded beneath - BTW please use Neil, Mr Benn is the
name of cartoon in Britain and I get the piss taken out of me for
it!!!!!!
Mr. Benn, you're saying something important here, but something
which merits, at least, qualification. Certainly the Java com-
munity has given considerable attention to the "write once, run
everywhere" goal. My own experience has been that their success
in regard to GUIs is mixed, at best.
<snip>

Err, well with Swing - I experienced very few cross platform issues
when using lightweight components - as soon as I introduce heavyweight
components into the equation - yes these issues start appearing. I
only use AWT when programming Personal Java/Profile (that API doesn;t
include Swing) and it's always a pain moving from one platform to
another. This is just a difference of opinion here and will always be
subjective.

Maybe it would help to clarify a bit--*which* "GUI toolkit" do
you have in mind? I *think* you're talking about Swing--is that
right?
<snip>

Quote from original e-mail - 'Java GUI (Swing ignore AWT for the point
of this'

Yes - swing, although I did embed that bit in brackets
My conclusion: while Java undeniably aspires to be portable in
its GUI, those with a stake in the outcome need to specify clearly
their requirements. Java does *not* currently provide perfect
portability.

I agree there isn't 'perfect portability' (partly because its
difficult to define perfect!!) but it is good - take a look at
something like jedit - it works across all platforms I've tried it on
(OSX, OS9, Windows, Solaris, Linux). For a quick test - get the look
and feel option in most java programs and flick about between the
different models - I think if performs commendably - much better than
the 'wrapper over native' type of GUI toolkits.

As a quick aside - does anyone know of a cross-language non native
GUI toolkit apart from Mozilla?

Cheers,

Neil