python from Java

[Ajay]

thanks a lot for that. its like a wakeup call - i have been looking at too
many things and not giving each enough time. i'll go with the SAX based
parsing and start with element tree.

thanks

cheers

p.s - by interface i meant just a set of "public" functions that you are
supposed to use, no GUI's.


Quoting Alan Kennedy <alanmk at hotmail.com>:

> [Ajay ]
>  >>>can you call a Python application from a Java program?
>
> [Alan Kennedy]
>  >>Define what you mean by "call a python application".
>
> [Ajay]
> > they are on the same machine.
> > basically there is an application that does some user modelling and
> its in
> > Python. the application (bunch of .py scripts) have an interface that
> you
> > use to access user models.
>
> OK, so you have a cpython application which is already running on your
> PDA. Presumably this "interface" you mention is a graphical interface,
> i.e. GUI? What graphics toolkit is this GUI written with? TkInter?
>
> > the java app will simply do some xml stuff at the end of which it will
> > access the user model through the interface.
>
> OK, so you want to process your (P3P?) xml files in java, which will
> extract data and then use that to somehow drive your cpython
> application?
>
> > basically what i'd like to know is if i have
> > #test.py
> > def foo(blah):
> >     return blah += 5
>
> OK, doing the above would be easy, if you could run jython on your PDA.
> You would just use jython to interpret the function instead of cpython,
> and everything would live inside the same virtual machine, which would
> be nice and tidy.
>
> However, it's very likely that your PDA has J2ME, i.e. Java 2 Micro
> Edition, in which case you won't be able to run jython, which requires
> facilities that J2ME doesn't support namely reflection. If you PDA has
> any other version of java, you could run jython.
>
> But that wouldn't be any use to you in the case of your standalone
> cpython GUI application anyway, since it is pretty much guaranteed that
> the GUI code in your cpython code is cpython specific, and won't run on
> jython anyway.
>
> > can i call foo from a Java class? more importantly what would i need
> to
> > install on the machine to be able to do that. the machine in question
> is a
> > PDA so there are some limitations on what can be installed and made to
> run
> > on it. Python runs and so does Java.
>
> Assuming that my assumptions about cpython GUIs and J2ME are correct,
> here are some options you might consider.
>
> 1. Somehow drive your cpython GUI by having your java program generate
> the relevant UI events, e.g. generate mouse-clicks, key-presses, etc.
> This is a common GUI testing technique. A product that does this on
> Windows is "autoit". I don't know if this will work on your windows PDA:
> if not there are probably similar products.
>
> 2. Connect your apps using something like pyro or CORBA. Pyro
> "transports function/method calls" over a socket, from a server to a
> client, and then returns the results over the same socket. If your PDA
> supported J2ME, you could use a pyro server on the cpython end, talking
> to a client on java end. But without J2ME, you can't use pyro on the
> client end. Which leaves CORBA, which should be well supported on both
> ends, but a bit more difficult to get your head around: i.e. you'll have
> a learning curve to climb to get it working. If this approach interests
> you, google "fnorb" or "omniorb python".
>
> 3. If CORBA is too complex for you, roll your own "wire protocol",
> basically your own simple protocol to communicate between cpython and
> java. Using this trategy, open some form of communication channel
> between the two programs, e.g. socket, pipe, fifo, etc, and send
> commands/messages between the two ends.
>
> Having seen your posts here and on the Python-CE list over the last few
> days, I can see that this problem is proving complex for you. I would
> urge you to stop looking at every technology on your PDA and trying to
> figure out how to glue them together.
>
> I think you should focus on being able to process your XML in cpython,
> i.e. try to keep all your technology in the same language and in the
> same process. You're overly complicating it otherwise.
>
> I think the best solution for you is to use and event-based python
> parser to parse your XML. Event based-based parsing, e.g. SAX, is
> generally pretty quick, even when it is written in pure python. The
> slowness you have been experiencing (I saw 10 minutes for pxdom to parse
> your xml files?) is because you're trying to build a DOM, i.e. a
> Document Object Model. DOM's are *huge* memory hogs, requiring very
> substantial amounts of memory and cpu to build, and in most cases are
> completely unsuitable for the problem at hand.
>
> What you should consider is building your own object model, based on the
> events generated by your SAX parser. Although this sounds hard, it is
> actually extremely easy, as this ActiveState cookbook entry shows.
>
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/149368
>
> There are also multiple cpython products which will build a python
> object model from XML events: all of these should be comparatively cpu
> and memory efficient.
>
> Objectify
> http://gnosis.cx/download/gnosis/xml/objectify
>
> Anobind
> http://uche.ogbuji.net/tech/4Suite/anobind/
>
> ElementTree
> http://effbot.org/downloads/#elementtree
>
> Try out an approach like the one above: it will greatly simplify your
> life. And it should be reasonably efficient in execution time.
>
> If none of the above works for you, post back again.
>
> regards,
>
> --
> alan kennedy
> ------------------------------------------------------
> email alan:              http://xhaus.com/contact/alan
> --
> http://mail.python.org/mailman/listinfo/python-list
>


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.