jython-dev — Discussion of developing and enhancing Jython itself(!) (not how to use Jython)

[Jython-dev] ANN: version 2.1 of zxJDBC

[brian z. <bz...@zi...>]

Version 2.1 of zxJDBC has just been released

The zxJDBC package provides a nearly 100% Python DB API 2.0 compliant
interface for database connectivity in Jython.  It is implemented
entirely in Java and makes use of the JDBC API.  This means any
database capable of being accessed through JDBC, either directly or
using the JDBC-ODBC bridge, can be manipulated using zxJDBC.

Go to the zxJDBC web page for more details:
  http://www.ziclix.com/zxjdbc

Download it here:
  http://prdownloads.sourceforge.net/zxjdbc/zxJDBC-2.1.zip
  http://prdownloads.sourceforge.net/zxjdbc/zxJDBC-2.1.tar.gz

What's new:
 - Added the ability to choose dynamic or static iteration of the underlying
   ResultSet (see the documentation for a discussion on when to use which
   flavor).
 - Added ability to instantiate a zxJDBC connection from a DataSource or
   through a JNDI lookup.
 - Added 'pipe' package to assist in transfering data between a sink and a
   source, such as another database, an xml document or csv file.
 - Fixed bug in PyCursor which did correctly add any SQLWarnings to .warnings
 - Fixed all thrown exceptions from within Java code to properly be caught in
   Python try/excepts.
 - Made all classes Jython 2.1 compatible by implementing ClassDictInit.
 - Added DataHandlerFilter to facilitate custom datahandlers.
 - Loads of new unit tests.
 - Some performance improvements.

Compatibility:
 - Tested with Jython 2.1a2+.  It might work with older versions, but it has
   not been tested.
 - Tested with Java 1.3.

thanks,

brian

Re: [Jython-dev] MINI-PEP: Alternative to jar scanning.

[<bc...@wo...>]

[Samuele]

> I'm a bit unhappy with the actual form of the proposal.
> It seems more a mixture/mismatch beetween things that are
> good for jython -jar and some that are good for java -jar ...

> > The RunJar startup utility shows how /applications/ can be deployed
> > using the "java -jar" syntax. An index is generated of all the java
> > packages in the java system and stored in the main jar file together
> > with manifest file like this:
> >
> >     Name: python.main
> >     Main-Script: mytest.py
> >
> >     Name: python.options
> >     python-security-respectJavaAccessibility: true
> >     python-skipcachedir: true
> >     python-prepath:
> >     python-path: mytest.jar
> >
> > (notice that the jar file that includes the $py.class files must be
> > available on sys.path.
> That's the critical part. It seems that the CWD should be
> the directory with the jar otherwise java -jar will fail ... or
> I'm mislooking something.

No, you are right.

> > We can't load python modules from resources yet
> I don't even know if that would be a good idea, maybe we should just load
> them through the Java system classloader as happen with jythonc-ed code.

Agreed. Eventually we have to find a way of adding this feature.

> >
> > Problems:
> >
> > - Because the JYTHON-PACKAGE-* files is found as resources, only one
> > version of a package index can be loaded. If the classes in a
> > javapackage is split over more than one jar file, only the class files
> > in the first jar will be loaded with "import *" and show up in
> > dir(javapackage).
> That's not a big problem,
> if you're using java -jar there is just one jar up to java extensions...

Yeah, but since the manifest can have a Class-Path entry that lists
other .jar files I think it would be common to include libraries like
xerces.jar and jython.jar in this way.

  http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html#Main Attributes

These jar files doesn't show up in the java.class.path property but the
classes in them are of course available.

> > - Python module can not be loaded as resources, so none of this helps
> > with the applet situation.
> But IMHO the solution for applets should be the same for java -jar
> vs. the solution for jython -jar ...

I agree. 

Lets forget about RunJar for now. Remaining is (I hope) yet another way
to support import of java packages in the situation where we can't scan
the jar file.


I have also considered a scheme where the indexer tool writes a resource
file named after the jar file:

   /META-INF/JYTHON-PACKAGES-jython

which contains a complete list of all java packages and the classes in
each package:

   org.python.core : ArgParser,AutoInternalTables,BytecodeLoader,...
   org.python.compilers : ...

An deployed application that knows about the jars it depends on, can
make sure that the java packages are totally initialized by calling a
new sys.addXXX method for each jar file:

   sys.add_jar("jython")

This idea demands more of the application, but avoids the problem where
a java package is split over multiple jar files.

regards,
finn

Re: [Jython-dev] MINI-PEP: Alternative to jar scanning.

[Samuele P. <pe...@in...>]

 Hi.

 I'm a bit unhappy with the actual form of the proposal.
 It seems more a mixture/mismatch beetween things that are
 good for jython -jar and some that are good for java -jar ...

 > The JYTHON-PACKAGE-* entries will be used by the package-manager's
 > packageExists()
 That's neat.

 >
 > The RunJar startup utility shows how /applications/ can be deployed
 > using the "java -jar" syntax. An index is generated of all the java
 > packages in the java system and stored in the main jar file together
 > with manifest file like this:
 >
 >     Name: python.main
 >     Main-Script: mytest.py
 >
 >     Name: python.options
 >     python-security-respectJavaAccessibility: true
 >     python-skipcachedir: true
 >     python-prepath:
 >     python-path: mytest.jar
 >
 > (notice that the jar file that includes the $py.class files must be
 > available on sys.path.
 That's the critical part. It seems that the CWD should be
 the directory with the jar otherwise java -jar will fail ... or
 I'm mislooking something.

 > We can't load python modules from resources yet
 I don't even know if that would be a good idea, maybe we should just load
 them through the Java system classloader as happen with jythonc-ed code.

 >
 > Problems:
 >
 > - Because the JYTHON-PACKAGE-* files is found as resources, only one
 > version of a package index can be loaded. If the classes in a
 > javapackage is split over more than one jar file, only the class files
 > in the first jar will be loaded with "import *" and show up in
 > dir(javapackage).
 That's not a big problem,
 if you're using java -jar there is just one jar up to java extensions...
 or are you referring to jars on sys.path? but then getClass() in the
 patch is suboptimal.

 > - The tool only scan jar and zip files when making the index. It does
 > not scan directories on the class path.
 This make sense.

 >
 > - Python module can not be loaded as resources, so none of this helps
 > with the applet situation.
 But IMHO the solution for applets should be the same for java -jar
 vs. the solution for jython -jar ...

 regards.

[Jython-dev] MINI-PEP: Alternative to jar scanning.

[<bc...@wo...>]

The problem of scanning jar files to discover the names of available
java packages comes up again and again in different embedded situations.
We have added some more sys.add_XXX() methods to aid with the task and
these methods have helped some, but we still have situations where the
application which embed jython doesn't have access to the file system.

Here I'll try to describe a solution that tries to improve the situation
further. It should be noted that I don't a solution that fixes all
problem and closes this FAQ forever.

I'll focus on the discovery of java packages. It is IMO far less
important to correctly discover the full contents of java packages. As a
result of my priorities, there are situations where dir(javapackage) and
"from java package import *" will return only a subset of the available
java classes defined in the javapackage.


The basis of my suggestion is a process of pre-indexing jar files for
the benefit of jython. The pre-indexing of performed by a tool that
re-writes the jar file with additional entries added in the META-INF
folder.

An index entry for some java package is the same as used in the cachedir
directory. If consists of a dictionary where the javapackage name is the
key and a comma separated lists of java classes is the string value. 

   { 'some.java.package' : 'Foo,Bar,Baz' }

(There is also support for differentiate between public and non-public
classes to support the respectJavaAccessibility option, but that is
encoded in the value string and we can ignore that for now)


The indexer tool will write a zip-entry for each java package discovered
with the name:

   META-INF/JYTHON-PACKAGE-some.java.package

The contents of the entries is the comma separated list of class names.


The JYTHON-PACKAGE-* entries will be used by the package-manager's
packageExists()


The tool can either index jar files one by one or it can index a series
of jar files and put the resulting index into one output jar.

Benefits:

A pre-indexed jar file can be used from jython without requiring that
the auto-indexer can see the .jar file on the class path.

The RunJar startup utility shows how /applications/ can be deployed
using the "java -jar" syntax. An index is generated of all the java
packages in the java system and stored in the main jar file together
with manifest file like this:

    Name: python.main
    Main-Script: mytest.py

    Name: python.options
    python-security-respectJavaAccessibility: true
    python-skipcachedir: true
    python-prepath:
    python-path: mytest.jar

(notice that the jar file that includes the $py.class files must be
available on sys.path. We can't load python modules from resources yet)

An application deployed this way does not have to create a cachedir.


Problems:

- Because the JYTHON-PACKAGE-* files is found as resources, only one
version of a package index can be loaded. If the classes in a
javapackage is split over more than one jar file, only the class files
in the first jar will be loaded with "import *" and show up in
dir(javapackage).

- Subpackages does not show with "import *" or dir(javapackage).

- The tool only scan jar and zip files when making the index. It does
not scan directories on the class path.

- Python module can not be loaded as resources, so none of this helps
with the applet situation.


A preliminary patch is available here:

> http://sourceforge.net/tracker/index.php?func=detail&aid=454329&group_id=12867&atid=312867

Comments are welcome.

regards,
finn

[Jython-dev] [ jython-Patches-454329 ] Pre-indexing of jar files.

[<no...@so...>]

Patches item #454329, was opened at 2001-08-22 13:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=312867&aid=454329&group_id=12867

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Finn Bock (bckfnn)
Assigned to: Nobody/Anonymous (nobody)
Summary: Pre-indexing of jar files.

Initial Comment:
Support for pre-indexed jar files and a tool to 
perform the indexing.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=312867&aid=454329&group_id=12867

[Jython-dev] [ jython-Patches-448158 ] IgnoreMethodTag

[<no...@so...>]

Patches item #448158, was opened at 2001-08-05 06:52
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=312867&aid=448158&group_id=12867

Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Finn Bock (bckfnn)
>Assigned to: Finn Bock (bckfnn)
Summary: IgnoreMethodTag

Initial Comment:
Selected methods and contructors of the java API can 
be hidden from jython with this patch.

----------------------------------------------------------------------

>Comment By: Finn Bock (bckfnn)
Date: 2001-08-22 12:57

Message:
Logged In: YES 
user_id=4201

Patch applied.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=312867&aid=448158&group_id=12867

[Jython-dev] Regd Jython class loader

[Saravanan B. (EWU) <Sar...@am...>]

Hi,
I have a very basic question and im a jython beginner.
do we have any API or function in Java or Jython to convert a Jython class to Java class?
i.e. lets say i have a jython class file namely foo.py
can i use this like as follows in my foo.java file:
foo.java:
========
Class jythonclass = SomeClass.someMethod("foo.py") (or) SomeClass.SomeMethod("foo");
jythonclass.method1();
jythonclass.method2();

Would this be possible ?

Please clarify me on this.
thanks and any help on this would be greatly appreciated.

B.Saravanan


B.Saravanan
Senior Engineer
Ericsson Wireless Communications Inc.
6455 Lusk Blvd, E242G
San Diego CA 92121
Tel: (858) 3326253
Fax: (858) 3327360

[Jython-dev] Status of execfile(InputStream)

[Norman H. <hen...@in...>]

Hello,

sorry for asking a dumb question. I would like to read Jython skripts
from arbitrary Java InputStreams, not just from local files.
The jyhton class documentation lists the method I need:

http://www.jython.org/docs/api/org/python/util/PythonInterpreter.html#execfile(j
ava.io.InputStream)

but there are no details, and the method does not seem to work.
What am I doing wrong, or should I just wait a little?

Thanks in advance,
Norman.



--- jython log while trying execfile(InputStream) ---

tech41> ~/java/jython-2.0/jython
Jython 2.0 on java1.3.0rc1 (JIT: null)
Type "copyright", "credits" or "license" for more information.
>>> print 2*3+4
10
>>> from java.io import FileInputStream
>>> execfile( FileInputStream( "demo.py" ))
Traceback (innermost last):
  File "<console>", line 1, in ?
TypeError: execfile(): 1st arg can't be coerced to String

>>> execfile( "demo.py" )
[output deleted: skript works...]

>>> fis = FileInputStream( "demo.py" )
>>> print fis.read()
[reading the stream works...]

[ now trying again...]
>>> fis = FileInputStream( "demo.py" )
>>> execfile( fis )
Traceback (innermost last):
  File "<console>", line 1, in ?
TypeError: execfile(): 1st arg can't be coerced to String

Re: [Jython-dev] [Q] Newbie's question

[Robert W. B. <rb...@di...>]

Hello Youn-Jin,

*moved to jyt...@li...

On Mon, 20 Aug 2001, Young-Jin Lee wrote:
> Hi, all.
> I have a question on the embedded Jython. It seems like that Jython
> enables a Java application to use a Python interpreter. Then I'm curious
> if the following is possible with Jython and Java. I have a Java
> application and I want to use one of the Python extension, VPython. Can
> my Java application call VPython's method if it uses Jython or not?
>
> Is there any other way for a Java application to use Python extension?
> Thanks in advance. I'm looking forward to hearing your advice.
>
> Young-Jin Lee

The safest way to say this is that Java can use any module/extension that
Jython can use.  Jython cannot use C extensions. If your VPython extension
is in C, then VPython will not run in Jython (without extra work).  If
your VPython extension has no C dependencies, test it in Jython to ensure
there are no unexpected problems.  If it tests OK, you're ready to use
it from Java.

Other choices:
Other projects have sought Java-CPython integration, but all such projects
have been quite for some time. There appears to be no activity on such a
tool other than Jython (although I've had trouble staying up with the
other Python lists lately, so could be mistaken).

Cheers,
Robert

Re: [Jython-dev] Embedding Python in Java application

[Mats W. <ma...@la...>]

At 09:30 PM 8/20/2001 +0000, Venkataraman Ramaswamy wrote:
>From
>Venkat
>
>Hi,
>
>I use Windows 2000 and I program in Java.
>
>I have installed Jython-2.1a3.  I can invoke Jython from command line
>by typign "Jython" and it runs well.  I want to embed it in a Java
>application.
>
>I tried running SimpleEmbedded.java, but I get error messages.
>I have specified below the classpath and path set by me.  I have
>also attached the errors produced.
>
>__________________________________________________
>ClassPath:
>.;.;C:\PROGRA~1\JMF21~1.1\lib\sound.jar;
>C:\PROGRA~1\JMF21~1.1\lib\jmf.jar;%systemroot%\java\classes;
>C:\jython-2.1a3;


The CLASSPATH does not include the Jython .jar file.
It needs to do so - not the Jython directory.

[Jython-dev] Embedding Python in Java application

[Venkataraman R. <po...@ho...>]

<html><div style='background-color:'><DIV>From</DIV>
<DIV>Venkat</DIV>
<DIV>&nbsp;</DIV>
<DIV>Hi,</DIV>
<DIV>&nbsp;</DIV>
<DIV>I use Windows 2000 and I program in Java.</DIV>
<DIV>&nbsp;</DIV>
<DIV>I have installed Jython-2.1a3.&nbsp; I can invoke Jython from command line</DIV>
<DIV>by typign "Jython" and it runs well.&nbsp; I want to embed it in a Java</DIV>
<DIV>application.</DIV>
<DIV>&nbsp;</DIV>
<DIV>I tried running SimpleEmbedded.java, but I get error messages.</DIV>
<DIV>I have specified below the classpath and path set by me.&nbsp; I have</DIV>
<DIV>also attached the errors produced.</DIV>
<DIV>&nbsp;</DIV>
<DIV>__________________________________________________</DIV>
<DIV>ClassPath:<BR>.;.;C:\PROGRA~1\JMF21~1.1\lib\sound.jar;<BR>C:\PROGRA~1\JMF21~1.1\lib\jmf.jar;%systemroot%\java\classes;<BR>C:\jython-2.1a3;</DIV>
<DIV><BR>Path:<BR>%SYSTEMROOT%\SYSTEM32;%SYSTEMROOT%;<BR>%SYSTEMROOT%\SYSTEM32\WBEM;<BR>C:\JDK1.3.1\BIN;C:\PYTHON21;C:\JYTHON-2.1a3;<BR>C:\PROGRAM FILES\BORLAND\CBUILDER3\BIN</DIV>
<DIV>Error message</DIV>
<DIV><BR>Exception in thread "main" java.lang.NullPointerException<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; at org.python.core.PyJavaClass.lookup(PyJavaClass.java:43)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; at org.python.core.PyObject.&lt;init&gt;(PyObject.java:46)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; at org.python.core.PySingleton.&lt;init&gt;(PySingleton.java:8)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; at org.python.core.PyNone.&lt;init&gt;(PyNone.java:10)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; at org.python.core.PySystemState.initStaticFields(PySystemState.java:391<BR>)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; at org.python.core.PySystemState.initialize(PySystemState.java:370)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; at org.python.core.PySystemState.initialize(PySystemState.java:344)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; at org.python.core.PySystemState.initialize(PySystemState.java:337)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; at org.python.util.PythonInterpreter.&lt;init&gt;(PythonInterpreter.java:63)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; at org.python.util.PythonInterpreter.&lt;init&gt;(PythonInterpreter.java:47)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; at SimpleEmbedded.main(SimpleEmbedded.java:8)<BR>_______________________________________________</DIV>
<DIV>&nbsp;</DIV>
<DIV>Can you let me what I am doing wrong ?</DIV>
<DIV>Thanking you</DIV>
<DIV>Venkat</DIV>
<DIV>21 Aug 2001</DIV></div><br clear=all><hr>Get your FREE download of MSN Explorer at <a href='http://go.msn.com/bql/hmtag_itl_EN.asp'>http://explorer.msn.com</a><br></html>

[Jython-dev] [Q] Newbie's question

[Young-Jin L. <yl...@ui...>]

Hi, all.
I have a question on the embedded Jython. It seems like that Jython =
enables a Java application to use a Python interpreter. Then I'm curious =
if the following is possible with Jython and Java. I have a Java =
application and I want to use one of the Python extension, VPython. Can =
my Java application call VPython's method if it uses Jython or not?
Is there any other way for a Java application to use Python extension?
Thanks in advance. I'm looking forward to hearing your advice.

Young-Jin Lee

RE: [Jython-dev] A proposal for jythonc -J / --compileropts

[Humbel O. <Otm...@bi...>]

>   [Finn Bock]
> > [Humbel Otmar]

=20
> >Please find below a possible solution to a small jythonc problem.
> >I hope it is not platform specific.=20
>=20
> I think it is. I can't test it, but quoting args should work correctly
> on unix. It is the braindead command interpreter on windows that is at
> fault here.
>=20
> >I am not sure if this should become a bug report.
>=20
> It should, please add one. Even if it is just a windows problem, it is
> still a problem.
Done (# 453301).

> >With the following change in jython/Tools/main.py (around line 150):
> >	elif opt in ('-J', '--compileropts'):
> >		options.jopts =3D3D arg.split(',')  # was arg.split()
before
>=20
> While I'm always in favor of a quick hack <wink>, this is isn't the
> right one. It would break working scripts for unix users and I have
> never seen other tools use this convention for passing options down to
> subcommands.
Fully agree. Thanks very much for pointing this out.

> I'm leaning more towards a fix where we can pass in the name of a
> (property?) file that contains further options and arguments.=20
> It isn't a
> good solution but it would be the same bad solution that windows have
> always used.
> That could also function as the workaround to the max 9 args=20
> restriction
> that we also suffer on windows.
Until then, I'll stick to the quick hack, but very locally
on our make server. To be able to - dynamically - target different
output directories just makes it a lot easier to run several different
builds every night.

Re: [Jython-dev] tried to submit to FAQ

[<bc...@wo...>]

[Marjorie Klenin]

>Sorry to be a pain, but did manage to log onto SourceForge, and hoped to
>submit this to your faq using my SF id and pwd.  It got refused.  Pls
>help!!

The faqwizard has its own password. It is not a great secret, you type
it every time you start the command interpreter.

OTOH, editing the faq is mostly intended for people who knows the
answers to common questions. It is best to send the questions to the
jython-users list.

regards,
finn

Re: [Jython-dev] A proposal for jythonc -J / --compileropts

[<bc...@wo...>]

[Humbel Otmar]

>Please find below a possible solution to a small jythonc problem.
>I hope it is not platform specific. 

I think it is. I can't test it, but quoting args should work correctly
on unix. It is the braindead command interpreter on windows that is at
fault here.

>I am not sure if this should become a bug report.

It should, please add one. Even if it is just a windows problem, it is
still a problem.

>With the following change in jython/Tools/main.py (around line 150):
>	elif opt in ('-J', '--compileropts'):
>		options.jopts =3D arg.split(',')  # was arg.split() before

While I'm always in favor of a quick hack <wink>, this is isn't the
right one. It would break working scripts for unix users and I have
never seen other tools use this convention for passing options down to
subcommands.

I'm leaning more towards a fix where we can pass in the name of a
(property?) file that contains further options and arguments. It isn't a
good solution but it would be the same bad solution that windows have
always used.

That could also function as the workaround to the max 9 args restriction
that we also suffer on windows.

regards,
finn

Re: [Jython-dev] tried to submit to FAQ

[Robert W. B. <rb...@di...>]

Hello,

On Sat, 18 Aug 2001, m klenin wrote:
> Sorry to be a pain, but did manage to log onto SourceForge, and hoped to
> submit this to your faq using my SF id and pwd.  It got refused.  Pls
> help!!
>
> Subject:Indefinite number of functional arguments
>
>
> Question:
>
>
> The statement (e.g.)
>
>      def functionName ( arg1,  *otherArgs)
>
> is really useful sometimes and has no real equivalent in java.
> Tried (with no success) all the ways I can think of to convert this to
> (e.g.)
>
>      public String functionName( java.lang.String arg1,
>                                  java.lang.String [] otherArgs )
>
> Does anyone have any suggestions?

The basics of this issue lies in the FAQ entry 5.3. Supporting keyword
arguments in Java Methods. The short story is use a sig like the
following:

    public PyObject myMethod(PyObject[] args, String[] kw)

Then parse those arguments with org.python.core.ArgParser

    ArgParser ap = new ArgParser("myMethod", args, kw, "Var1");


I changed the title of that FAQ entry, and added a note about referencing
the Javadocs for org.python.core.ArgParser. I hope this is OK with others.

New title= "5.3. Supporting *args and **kw in Java methods"
This might not be ideal either, but it will catch more curious eyes
because of the "*args, **kw" familiarity to Python folk.

Cheers,
Robert

Re: [Jython-dev] tried to submit to FAQ

[Samuele P. <pe...@in...>]

Hi.

> Subject:Indefinite number of functional arguments
>
>
> Question:
>
>
> The statement (e.g.)
>
>      def functionName ( arg1,  *otherArgs)
>
> is really useful sometimes and has no real equivalent in java.
> Tried (with no success) all the ways I can think of to convert this to
> (e.g.)
>
>      public String functionName( java.lang.String arg1,
>                                  java.lang.String [] otherArgs )
>
> Does anyone have any suggestions?

That's really the typical java idiom to achieve that:

... meth(...,<a-specific-type>[] rest)
... meth(...,Object[] rest)

and at call site:
  anObj.meth(..., new <your-type>[] {expr,....} )

but if also at call site your rest argument should be programmatically
constructed (they number is known at runtime only)
you can use either a Vector or an ArrayList (with Java2):

java.util.ArrayList rest = new java.util.ArrayList();
... fill up rest
meth.func(...,rest.toArray(new <your-type>[0]))

if <your-type> is Object, then the parameter-less version of toArray is fine.

Depending on some trade-offs you could use ArrayList(Vector) instead of the
array type in meth signature.

More a Java FAQ than a jython one <wink>.

regards, Samuele Pedroni

[Jython-dev] tried to submit to FAQ

[m k. <m_k...@nc...>]

Sorry to be a pain, but did manage to log onto SourceForge, and hoped to
submit this to your faq using my SF id and pwd.  It got refused.  Pls
help!!

Subject:Indefinite number of functional arguments


Question:


The statement (e.g.)

     def functionName ( arg1,  *otherArgs) 

is really useful sometimes and has no real equivalent in java. 
Tried (with no success) all the ways I can think of to convert this to 
(e.g.)

     public String functionName( java.lang.String arg1, 
                                 java.lang.String [] otherArgs )

Does anyone have any suggestions?

-- 
Marjorie Klenin
physics, box 8202
North Carolina State University
Raleigh NC 27695-8202  USA

email:m_k...@nc...
phone: 919.515.7457

RE: [Jython-dev] A proposal for jythonc -J / --compileropts

[Humbel O. <Otm...@bi...>]

Hello,

Sorry for the bad formatting in the previous post. Here is a hopefully
improved one.

Please find below a possible solution to a small jythonc problem.=20
I hope it is not platform specific. I am not sure if this should become
a bug report.

Typing:
	[appl|pwe] > 	jythonc=20
			  	--package CH.obj.Libraries.Test=20
	             	--workdir e:/temp=20
                  	--compileropts "-g -d e:/pwe_appl/out"
			  	WorkflowRuntimeFactoryImpl.py
results in:
	Could not find class: e:/pwe_appl/out

With the following change in jython/Tools/main.py (around line 150):
	elif opt in ('-J', '--compileropts'):
		options.jopts =3D arg.split(',')  # was arg.split() before
we can type:
	[appl|pwe] > 	jythonc=20
				--package CH.obj.Libraries.Test=20
	             	--workdir e:/temp=20
	             	--compileropts -g,-d,e:/pwe_appl/out
	             	WorkflowRuntimeFactoryImpl.py
and successfully get:=20
	processing WorkflowRuntimeFactoryImpl
		<snipped> =09
	Compiling .java to .class...
	Compiling with args:=20
	['c:\\jdk1.3\\bin\\javac', '-g', '-d','e:/pwe_appl/out',=20
	'-classpath',=20
		<rest of javac command snipped> =09
	0  Note:
	e:\temp\CH\obj\Libraries\Test\WorkflowRuntimeFactoryImpl.java=20
	uses or overrides a deprecated API.
	Note: Recompile with -deprecation for details.

This change would match the behaviour of --falsenames, but I don't know
if it is reasonable. I did not test the behaviour of the setting of
python.jythonc.compileropts in the registry.=20
Of course the documentation in jythonc.html (and in main.py around line
50) would need to be updated to:
	--compileropts / -J options:
	A comma separated list of options passed directly to the Java
	compiler.	Alternatively, you can set the property
	python.jythonc.compileropts in the registry.

My configuration is as follows:
	on Windows NT
	[appl|pwe] > jython
	Jython 2.0 on java1.3.0 (JIT: null)
	Type "copyright", "credits" or "license" for more information.

Best wishes,
Oti.

[Jython-dev] A proposal for jythonc -J / --compileropts

[Humbel O. <Otm...@bi...>]

Hello,

Please find below a possible solution to a small jythonc problem. I hope
it is not platform specific. I am not sure if this should become a bug
report.

Typing:
	[appl|pwe] > jythonc --package CH.obj.Libraries.Test --workdir
e:/temp=20
                  --compileropts "-g -d e:/pwe_appl/out"
WorkflowRuntimeFactoryImpl.py
results in:
	Could not find class: e:/pwe_appl/out

With the following change in jython/Tools/main.py (around line 150):
	elif opt in ('-J', '--compileropts'):
		options.jopts =3D arg.split(',')       # was arg.split()
before
we can type:
	[appl|pwe] > jythonc --package CH.obj.Libraries.Test --workdir
e:/temp=20
	             --compileropts -g,-d,e:/pwe_appl/out
WorkflowRuntimeFactoryImpl.py
and successfully get:=20
	processing WorkflowRuntimeFactoryImpl
		<snipped> =09
	Compiling .java to .class...
	Compiling with args: ['c:\\jdk1.3\\bin\\javac', '-g', '-d',
'e:/pwe_appl/out', '-classpath',=20
		<rest of javac command snipped> =09
	0  Note:
e:\temp\CH\obj\Libraries\Test\WorkflowRuntimeFactoryImpl.java uses or
overrides a deprecated API.
	Note: Recompile with -deprecation for details.

This change would match the behaviour of --falsenames, but I don't know
if it is reasonable. I did not test the behaviour of the setting of
python.jythonc.compileropts in the registry.=20
Of course the documentation in jythonc.html (and in main.py around line
50) would need to be updated to:
	--compileropts / -J options:
	A comma separated list of options passed directly to the Java
compiler.
	Alternatively, you can set the property
python.jythonc.compileropts in the registry.

My configuration is as follows:
	on Windows NT
	[appl|pwe] > jython
	Jython 2.0 on java1.3.0 (JIT: null)
	Type "copyright", "credits" or "license" for more information.
	>>>=20

Best wishes,
Oti.

Re: [Jython-dev] skeleton benchmarks

[john c. <joh...@ya...>]

Cool, I will provide supporting code as well.


--- Finn Bock <bc...@wo...> wrote:
> [John Coppola]
> 
> >Was the results of this experiment uninteresting?
> No
> >comments?  There seemed to be a lot of enthusiasm
> at
> >one point but no longer.  Hmmm... what are you
> fellas
> >up to?
> 
> I'm reviewing a book, implementing the _weakref
> module and fixing some
> random jython bugs. Thanks for asking <wink>.
> 
> Your finding of a 8x speedup matches my own
> experience when I
> implemented cPickle and cStringIO. Hardening a
> non-trivial python module
> into a java class can typically give 5x to 9x faster
> code. 
> 
> The fact that cPickle.java looks so much faster then
> pickle.py is due to
> the extremely low performing (on jython) way
> pickle.py reads strings
> from the pickle. Each string read from a file cause
> the compilation,
> creation and loading of a new java class.
> cPickle.java avoids this by
> reaching deep into the internal jython
> implementation to reuse the
> string parsing from the parser.
> 
> I'll look closer at your example over the weekend.
> 
> regards,
> finn
> 
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
>
http://lists.sourceforge.net/lists/listinfo/jython-dev


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

Re: [Jython-dev] skeleton benchmarks

[<bc...@wo...>]

[John Coppola]

>Was the results of this experiment uninteresting? No
>comments?  There seemed to be a lot of enthusiasm at
>one point but no longer.  Hmmm... what are you fellas
>up to?

I'm reviewing a book, implementing the _weakref module and fixing some
random jython bugs. Thanks for asking <wink>.

Your finding of a 8x speedup matches my own experience when I
implemented cPickle and cStringIO. Hardening a non-trivial python module
into a java class can typically give 5x to 9x faster code. 

The fact that cPickle.java looks so much faster then pickle.py is due to
the extremely low performing (on jython) way pickle.py reads strings
from the pickle. Each string read from a file cause the compilation,
creation and loading of a new java class. cPickle.java avoids this by
reaching deep into the internal jython implementation to reuse the
string parsing from the parser.

I'll look closer at your example over the weekend.

regards,
finn

Re: [Jython-dev] skeleton benchmarks

[john c. <joh...@ya...>]

Was the results of this experiment uninteresting?  No
comments?  There seemed to be a lot of enthusiasm at
one point but no longer.  Hmmm... what are you fellas
up to?  I would really like to refine this idea, and
will need your help doing so.

Note: because of the size of the text box window, the
code is not formatted correctly.  But it is easy to
deduce how it is supposed to look like. 




--- john coppola <joh...@ya...> wrote:
> So, this weekend I got a working prototype of the
> skeletons model functioning.
> 
> The speed boost for batch processing was roughly 8x
> faster than regular native Jython.  Not quite the
> speed boost I was looking for.  I was hoping for at
> least 20x performance boost.
> 
> Here are the simple data structures used:
> 
> class DataRecord:
>     def __init__(self):
>         self.name = 'test'
>         self.wage  = 10.0
>         self.hours =  40.0
> 
> class WorkHistory:
>     def __init__(self):
>         self.name = 'test'
>         self.workhistory = []
> 
>     def add_record(self,ob):
>         self.workhistory.append(ob)
> 
>     def compute_total(self):
>         total = 0.0
>         for ob in self.workhistory:
>             total = total + ob.wage*ob.hours
>         return total
> 
> def test():
>     from time import time
>     wh=WorkHistory()
>     # populate wh
>     for i in xrange(0,1000):
>         wh.add_record(DataRecord())
>     start = time()
>     wh.compute_total()
>     print time()-start
> 
> So in native Jython without skeletons this took:
>    0.03 seconds to calculate
> 
> Now skeletons where applied in this way using getter
> and setter style methods on native java skeleton
> class.
> 
> public class WorkHistorySkeleton extends
> PyJavaSkeleton {
>     public PyList workhistory = new PyList();
> 
>     public void set_workhistory(PyObject ob) {
>         workhistory = ob;
>     }
> 
>     public PyList get_workhistory() {
>         return workhistory;
>     }
> 
>     public double compute_total() {
>         double total = 0.0;
>         for (int i;i<workhistory.__len__();i++) {
>             PyObject ob =
> workhistory.__getitem__(i);
>             DataRecordSkeleton sk =
> (DataRecordSkeleton) ob.__skeleton__()
>             total += sk.wage*sk.hours
>         }
>         return total
>     }
> }
> 
> public class DataRecordSkeleton extends
> PyJavaSkeleton
> {
>     public double wage = 0.0;
>     public double hours = 0.0;
> 
>     public void set_wage(PyObject ob) {
>         wage=((PyFloat) ob).getValue();
>     }
>     public double get_wage() {
>         return wage;
>     }
>     
>     public void set_hours(PyObject ob) {
>         hours=((PyFloat) ob).getValue();
>     }
>     public double get_hours() {
>         return hours;
>     }
> }
> 
> So for my test:
> def test():
>     from time import time
>    
wh=WorkHistory(__skeleton__='WorkHistorySkeleton')
>     # populate wh
>     for i in xrange(0,1000):
>        
>
wh.add_record(DataRecord(__skeleton__='DataRecordSkeleton'))
>     start = time()
>     wh.compute_total()
>     print time()-start
> 
> it takes 0.0036 seconds for this code to execute
> with
> skeletons.
> 
> 
> Perhaps multiple inheretence is the way to go for
> this. But there are still some issues that have to
> be
> addressed.  In this code, we can explicitly retrieve
> the skeleton object and use it directly in native
> java
> because it is native java.  To utilize the speed of
> native java from a hybrid class inhereting from both
> a
> java class and a python class a technique must be
> developed to rapidy retrieve only that part of the
> object's construction.  This way we can work with
> the
> native java component of the object without the need
> for ((PyFloat)__findattr__('<name>')).getValue() or
> __findattr__('<name>').__str__() or whatever.  This
> layer is removed thus making things faster.
> 
> Also ob.__skeleton__() is a one step process and the
> skeleton backbone is retrieved.  The hypothetical
> coersion mechanism developed to retrieve only the
> java
> part of an object would have to be atleast as fast
> as
> the ob.__skeleton__() method.
> 
> For people following this thread, please let me know
> what you think.  If you'd like to see the actual
> code
> I've whipped up let me know cause the code here I
> wrote out of my head (dont have my laptop with me).
> 
> So, let me know what you think.
> 
> peace,
> John Coppola
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Send instant messages & get email alerts with Yahoo!
> Messenger.
> http://im.yahoo.com/
> 
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
>
http://lists.sourceforge.net/lists/listinfo/jython-dev


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

Re: [Jython-dev] skeleton benchmarks

[john c. <joh...@ya...>]

Was the results of this experiment uninteresting?  No
comments?  There seemed to be a lot of enthusiasm at
one point but no longer.  Hmmm... what are you fellas
up to?  I would really like to refine this idea, and
will need your help doing so.

Note: because of the size of the text box window, the
code is not formatted correctly.  But it is easy to
deduce how it is supposed to look like. 




--- john coppola <joh...@ya...> wrote:
> So, this weekend I got a working prototype of the
> skeletons model functioning.
> 
> The speed boost for batch processing was roughly 8x
> faster than regular native Jython.  Not quite the
> speed boost I was looking for.  I was hoping for at
> least 20x performance boost.
> 
> Here are the simple data structures used:
> 
> class DataRecord:
>     def __init__(self):
>         self.name = 'test'
>         self.wage  = 10.0
>         self.hours =  40.0
> 
> class WorkHistory:
>     def __init__(self):
>         self.name = 'test'
>         self.workhistory = []
> 
>     def add_record(self,ob):
>         self.workhistory.append(ob)
> 
>     def compute_total(self):
>         total = 0.0
>         for ob in self.workhistory:
>             total = total + ob.wage*ob.hours
>         return total
> 
> def test():
>     from time import time
>     wh=WorkHistory()
>     # populate wh
>     for i in xrange(0,1000):
>         wh.add_record(DataRecord())
>     start = time()
>     wh.compute_total()
>     print time()-start
> 
> So in native Jython without skeletons this took:
>    0.03 seconds to calculate
> 
> Now skeletons where applied in this way using getter
> and setter style methods on native java skeleton
> class.
> 
> public class WorkHistorySkeleton extends
> PyJavaSkeleton {
>     public PyList workhistory = new PyList();
> 
>     public void set_workhistory(PyObject ob) {
>         workhistory = ob;
>     }
> 
>     public PyList get_workhistory() {
>         return workhistory;
>     }
> 
>     public double compute_total() {
>         double total = 0.0;
>         for (int i;i<workhistory.__len__();i++) {
>             PyObject ob =
> workhistory.__getitem__(i);
>             DataRecordSkeleton sk =
> (DataRecordSkeleton) ob.__skeleton__()
>             total += sk.wage*sk.hours
>         }
>         return total
>     }
> }
> 
> public class DataRecordSkeleton extends
> PyJavaSkeleton
> {
>     public double wage = 0.0;
>     public double hours = 0.0;
> 
>     public void set_wage(PyObject ob) {
>         wage=((PyFloat) ob).getValue();
>     }
>     public double get_wage() {
>         return wage;
>     }
>     
>     public void set_hours(PyObject ob) {
>         hours=((PyFloat) ob).getValue();
>     }
>     public double get_hours() {
>         return hours;
>     }
> }
> 
> So for my test:
> def test():
>     from time import time
>    
wh=WorkHistory(__skeleton__='WorkHistorySkeleton')
>     # populate wh
>     for i in xrange(0,1000):
>        
>
wh.add_record(DataRecord(__skeleton__='DataRecordSkeleton'))
>     start = time()
>     wh.compute_total()
>     print time()-start
> 
> it takes 0.0036 seconds for this code to execute
> with
> skeletons.
> 
> 
> Perhaps multiple inheritence is the way to go for
> this. But there are still some issues that have to
> be
> addressed.  In this code, we can explicitly retrieve
> the skeleton object and use it directly in native
> java
> because it is native java.  To utilize the speed of
> native java from a hybrid class inheriting from both
> a
> java class and a python class a technique must be
> developed to rapidly retrieve only that part of the
> object's construction.  This way we can work with
> the
> native java component of the object without the need
> for ((PyFloat)__findattr__('<name>')).getValue() or
> __findattr__('<name>').__str__() or whatever.  This
> layer is removed thus making things faster.
> 
> Also ob.__skeleton__() is a one step process and the
> skeleton backbone is retrieved.  The hypothetical
> coercion mechanism developed to retrieve only the
> java
> part of an object would have to be at least as fast
> as
> the ob.__skeleton__() method.
> 
> For people following this thread, please let me know
> what you think.  If you'd like to see the actual
> code
> I've whipped up let me know cause the code here I
> wrote out of my head (dont have my laptop with me).
> 
> So, let me know what you think.
> 
> peace,
> John Coppola
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Send instant messages & get email alerts with Yahoo!
> Messenger.
> http://im.yahoo.com/
> 
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
>
http://lists.sourceforge.net/lists/listinfo/jython-dev


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

[Jython-dev] freshmeat project listing for Jython

[jeff c. <jef...@fr...>]

I'm writing in reference to your project
"Jython".

Since the time you submitted this project to us, freshmeat has adopted
a new categorization system which allows much more fine-grained
organization of projects.  Since your project has never been
recategorized under this system, our readers aren't finding your
project when they browse through categories where it should be listed.

We'd like to ask you to take just a few minutes to recategorize your
project.  You should delete any categories which begin with "Old
Appindex" and add all of the new categories which apply to your
project.  You can edit your project listing at:

http://freshmeat.net/projects/jython/

with the "recategorize" function in the menu.  While you're there,
take a moment to make sure everything else is up-to-date.  If you have
any problems, please let us know at http://freshmeat.net/contact/.

Thanks for listing your project in our database.

Sincerely,
Jeff Covey