python from Java

[Ajay]

hi!

can you call a Python application from a Java program? does this require
any additional package to be installed?

thanks

cheers

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

[Fidel Viegas]

Ajay wrote:

hi!

can you call a Python application from a Java program? does this require
any additional package to be installed?

Have a look at jython (http://www.jython.org)

All the best

Fidel.

[Alan Kennedy]

[Ajay ]

can you call a Python application from a Java program? does this require
any additional package to be installed?

Define what you mean by "call a python application".

Are the python code and java code in the same process?

Are they on the same machine?

Are they on different machines connected on a network?

Etc, etc.

--
alan kennedy
------------------------------------------------------
email alan: http://xhaus.com/contact/alan

[Ajay]

hi!

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.
the java app will simply do some xml stuff at the end of which it will
access the user model through the interface.
basically what i'd like to know is if i have
#test.py
def foo(blah):
return blah += 5

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.

cheers

Quoting Alan Kennedy <al****@hotmail.com>:

[Ajay ]

can you call a Python application from a Java program? does this

require

any additional package to be installed?

Define what you mean by "call a python application".

Are the python code and java code in the same process?

Are they on the same machine?

Are they on different machines connected on a network?

Etc, etc.

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

[Alan Kennedy]

[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/Coo.../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

[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 <al****@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/Coo.../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.

[Ajay]

Quoting Alan Kennedy <al****@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/Coo.../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

okay i tried the above approaches but no luck. See the problem is an XML
parser which works on a PDA - pythonce. Now elementtree uses pyexpat
(which pythonce doesn't have), objectify just needs expat which i dont
have either and anobind needs 4Suite - there is no port for it to a PDA.
so i am back to where i was earlier.
looking for a reasonably fast and efficient xml parser that works on a PDA
(DOM or SAX, i dont care)

cheers


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.

[Richie Hindle]

[Ajay]

[...] the problem is an XML
parser which works on a PDA - pythonce. Now elementtree uses pyexpat
(which pythonce doesn't have), objectify just needs expat which i dont
have either and anobind needs 4Suite - there is no port for it to a PDA.
so i am back to where i was earlier.
looking for a reasonably fast and efficient xml parser that works on a PDA
(DOM or SAX, i dont care)

Try Beautiful Soup: http://www.crummy.com/software/BeautifulSoup/ (you'll
want the BeautifulStoneSoup parser). I don't know whether it's fast or
efficient, but it's pure Python so it should run in your environment.

--
Richie Hindle
ri****@entrian.com

[Alan Kennedy]

[Alan Kennedy]

I think the best solution for you is to use and event-based python
parser to parse your XML.
and
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/Coo.../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

[Ajay] okay i tried the above approaches but no luck. See the problem is an XML
parser which works on a PDA - pythonce. Now elementtree uses pyexpat
(which pythonce doesn't have), objectify just needs expat which i dont
have either and anobind needs 4Suite - there is no port for it to a PDA.
so i am back to where i was earlier.
looking for a reasonably fast and efficient xml parser that works on a PDA
(DOM or SAX, i dont care)

I see.

OK, rather than us trying to suggest multiple possible solutions, only
to find out that they are not supported on python-ce, because of lack of
expat, etc, please can you list for us the xml parsers that *do* work on
python-ce.

Particularly, I'm interested in whether the xml.sax modules work. Also,
check to see if sgmllib works, since that can also be used as an
efficient XML parser. There's got to be *some* event-based XML parser on
python-ce, even if it is pure-python.

Start by looking at this HOWTO, and see if you can get any of the
examples running.

http://pyxml.sourceforge.net/topics/...ction-SAX.html

Once you've got a working event parser, then we'll figure out the best
way to build a python object model for your xml files.

regards,

--
alan kennedy
------------------------------------------------------
email alan: http://xhaus.com/contact/alan

[Ajay]

hi!

i have xmlproc working and i can build a minidom pretty quickly using it,
which means i can port my exisiting DOM code to the PDA.
but i am going to use SAX and build the object model you mentioned and use
that.
just a question, how hard would it be to actually perform the comparison
using C. ie, pass the dom/object model to a C module and have it do the
comparison. it should considerably speed up things and maybe the best time
to try my knowledge of C. the part i am worried about with using C is
converting the datatypes, ie the object model/minidom to something else in
C.

anyways thanks for your help and suggestions....why didn't i try xmlproc
earlier and a dom with xmlproc is quite fast....well atleast compared to
pxdom.

thanks

cheers
Quoting Alan Kennedy <al****@hotmail.com>:

[Alan Kennedy]

I think the best solution for you is to use and event-based python
parser to parse your XML.
and
What you should consider is building your own object model, based on theevents 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/Coo.../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

[Ajay]

okay i tried the above approaches but no luck. See the problem is an

XML

parser which works on a PDA - pythonce. Now elementtree uses pyexpat
(which pythonce doesn't have), objectify just needs expat which i

dont

have either and anobind needs 4Suite - there is no port for it to a

PDA.

so i am back to where i was earlier.
looking for a reasonably fast and efficient xml parser that works on a

PDA

(DOM or SAX, i dont care)

I see.

OK, rather than us trying to suggest multiple possible solutions, only
to find out that they are not supported on python-ce, because of lack of
expat, etc, please can you list for us the xml parsers that *do* work on
python-ce.

Particularly, I'm interested in whether the xml.sax modules work. Also,
check to see if sgmllib works, since that can also be used as an
efficient XML parser. There's got to be *some* event-based XML parser on
python-ce, even if it is pure-python.

Start by looking at this HOWTO, and see if you can get any of the
examples running.

http://pyxml.sourceforge.net/topics/...ction-SAX.html

Once you've got a working event parser, then we'll figure out the best
way to build a python object model for your xml files.

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.

[Alan Kennedy]

[Ajay]

i have xmlproc working and i can build a minidom pretty quickly using it,
which means i can port my exisiting DOM code to the PDA.
That's good. So now you have fallback position that gives acceptable
performance.
but i am going to use SAX and build the object model you mentioned and use
that.
This will undoubtedly be faster than minidom, because you would be
building a simpler data structure. Also, it's a great way to learn what
DOM is actually doing for you. It's amazing how many people don't know.
just a question, how hard would it be to actually perform the comparison
using C. ie, pass the dom/object model to a C module and have it do the
comparison.
Well, that depends on the nature of the comparison operation. You'd have
to be more specific.
it should considerably speed up things and maybe the best time
to try my knowledge of C. the part i am worried about with using C is
converting the datatypes, ie the object model/minidom to something else in
C.
Don't fall into the trap of premature optimisation.

First, make it work!
Then, make it fast!
anyways thanks for your help and suggestions....why didn't i try xmlproc
earlier and a dom with xmlproc is quite fast....well atleast compared to
pxdom.

I've read several times that pxdom performance is not good. Fred Lundh
wrote the following about it:

"Sometimes, you wonder if people who releases Python libraries has ever
used them in any real applications. .. [snip] .. The pxdom toolkit is
500 times slower than other portable implementations, and 3300 times
slower than the fastest XML object implementation I have on this
machine. Put another way, pxdom parses 4350 bytes per second on a 3 GHz
PC. 690,000 cycles per byte. Wow."

http://online.effbot.org/2004_08_01_...e.htm#20040820

regards,

--
alan kennedy
------------------------------------------------------
email alan: http://xhaus.com/contact/alan

[Fredrik Lundh]

"Ajay" <ab******@mail.usyd.edu.au> wrote:

ElementTree
http://effbot.org/downloads/#elementtree

okay i tried the above approaches but no luck. See the problem is an XML
parser which works on a PDA - pythonce. Now elementtree uses pyexpat
(which pythonce doesn't have)

that's why ElementTree ships with several alternative tree builders;
from the README:

SimpleXMLTreeBuilder.py
Old element tree builder for XML, based on
xmllib, for Python versions where "expat" is
not available

usage:

from elementtree import ElementTree, SimpleXMLTreeBuilder

tree = ElementTree.parse(
source, SimpleXMLTreeBuilder.TreeBuilder()
)

note that xmllib has problems with namespaces on some versions
of Python; see the elementtree README for details.

</F>

[Fredrik Lundh]

okay i tried the above approaches but no luck. See the problem is an XML
parser which works on a PDA - pythonce. Now elementtree uses pyexpat
(which pythonce doesn't have)

that's why ElementTree ships with several alternative tree builders.

by the way, it's trivial to build trees from arbitrary SAX-style sources.
just create an instance of the ElementTree.TreeBuilder class, and call
the "start", "end", and "data" methods as appropriate.

builder = ElementTree.TreeBuilder()
builder.start("tag", {})
builder.data("text")
builder.end("tag")
elem = builder.close()

</F>

[John J. Lee]

Alan Kennedy <al****@hotmail.com> writes:
[...]

I've read several times that pxdom performance is not good. Fred Lundh
wrote the following about it:

"Sometimes, you wonder if people who releases Python libraries has
ever used them in any real applications. .. [snip] .. The pxdom
toolkit is 500 times slower than other portable implementations, and
3300 times slower than the fastest XML object implementation I have on
this machine. Put another way, pxdom parses 4350 bytes per second on a
3 GHz PC. 690,000 cycles per byte. Wow."

[...]

A bit harsh: the poor fellow did explicitly say when he released it
that performance was a not an issue for him, and that prospective
users should watch out for this problem.

Having said that, a million ops per byte *is* a LITTLE slow! :-)

In fact, slow enought that I wonder if it couldn't be fixed fairly
easily...
John