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

Discussion in 'Python' started by F. GEIGER, Sep 29, 2004.

  1. F. GEIGER

    F. GEIGER Guest

    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
    F. GEIGER, Sep 29, 2004
    #1
    1. Advertising

  2. F. GEIGER

    Steve Menard Guest

    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
    Steve Menard, Sep 30, 2004
    #2
    1. Advertising

  3. F. GEIGER

    F. GEIGER Guest

    "Steve Menard" <> schrieb im Newsbeitrag
    news:1DI6d.223$...

    <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
    F. GEIGER, Sep 30, 2004
    #3
  4. F. GEIGER

    Ville Vainio Guest

    >>>>> "f.geiger" == F GEIGER <> 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
    Ville Vainio, Sep 30, 2004
    #4
  5. F. GEIGER

    F. GEIGER Guest

    "Ville Vainio" <> schrieb im Newsbeitrag
    news:...
    > >>>>> "f.geiger" == F GEIGER <> 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
    F. GEIGER, Oct 1, 2004
    #5
  6. F. GEIGER

    Neil Benn Guest

    Ville Vainio wrote:

    >>>>>>"f.geiger" == F GEIGER <> 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 : +49 (0)351 4173 154
    e-mail :
    Cenix Website : http://www.cenix-bioscience.com
    Neil Benn, Oct 1, 2004
    #6
  7. GUI development: Java vs. Python (was: Calling (C)Python code from Java: Is it JPype?)

    In article <>,
    Neil Benn <> 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

    .
    .
    .
    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.

    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?

    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.
    Cameron Laird, Oct 1, 2004
    #7
  8. Test-driven GUI development (was: Calling (C)Python code from Java: Is it JPype?)

    In article <cjjksb$soo$>, F. GEIGER <> wrote:
    .
    .
    .
    >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.

    .
    .
    .
    >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.

    .
    .
    .
    These are good and important points, ones that deserve a more
    complete answer than I can express now. Until such experts as
    Peter and Alex chime in, though, please do keep in mind that,
    for at least some of us, test-driven GUI development in Python
    is not only possible, but *superior*, to the practices you
    describe with, for example, Java. You apparently have habits
    that work well for you with Java; that's great. I think that
    you'll eventually be even happier with a more Pythonic approach.
    I hope some of us can make it clear in follow-ups.
    Cameron Laird, Oct 1, 2004
    #8
  9. F. GEIGER

    Ville Vainio Guest

    >>>>> "geiger" == F GEIGER <> 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
    Ville Vainio, Oct 2, 2004
    #9
  10. F. GEIGER

    Neil Benn Guest

    Re: GUI development: Java vs. Python (was: Calling (C)Python code from Java: Is it JPype?)

    (Cameron Laird) wrote in message news:<>...
    > In article <>,
    > Neil Benn <> 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
    Neil Benn, Oct 2, 2004
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Wolfgang Keller

    JMS for CPython via JPype?

    Wolfgang Keller, Nov 2, 2004, in forum: Python
    Replies:
    7
    Views:
    1,240
    Steve Menard
    Nov 6, 2004
  2. Tim Couper

    JPype download?

    Tim Couper, Nov 10, 2004, in forum: Python
    Replies:
    2
    Views:
    359
    Steve Menard
    Nov 11, 2004
  3. Joachim Boomberschloss

    Re: Integration with java (Jpype vs. JPE)

    Joachim Boomberschloss, Jan 18, 2005, in forum: Python
    Replies:
    1
    Views:
    475
    Irmen de Jong
    Jan 18, 2005
  4. skn
    Replies:
    4
    Views:
    552
  5. Replies:
    6
    Views:
    473
    Alan Kennedy
    Aug 14, 2007
Loading...

Share This Page