From: Albert C. <ca...@uc...> - 2005-10-31 00:00:22
|
Dear all, Our use of jython is to script the image manipulation package ImageJ ( http://rsb.info.nih.gov/ij , http://www.pensament.net/java/other_plugins.html#jython ). It would be very convenient for our non-programmer users to avoid the "import" statements when they have to do with java classes, i.e. to have jython check automatically for a java class by looking up the hashtable of all java class names in the classpath, and importing internally as appropriate in the PythonInterpreter. We can implement that manually ourselves but I understand it may be redundant since most of the required elements (the java classes hastable for example) may exist already within jython. Further, I support the view that the "import" statements are a compiler convenience, not truly essential to the writing of any python script, and thus the importing functionality should be part of the interpreter. Thanks to whoever is developing jython. Amazingly useful! Albert -- Albert Cardona Molecular Cell Developmental Biology University of California Los Angeles Tel +1 310 2067376 http://www.pensament.net/java/ http://www.mcdb.ucla.edu/Research/Hartenstein/ |
From: Diez B. R. <de...@we...> - 2005-10-31 00:17:52
|
> Our use of jython is to script the image manipulation package ImageJ ( > http://rsb.info.nih.gov/ij , > http://www.pensament.net/java/other_plugins.html#jython ). > It would be very convenient for our non-programmer users to avoid the > "import" statements when they have to do with java classes, i.e. to have > jython check automatically for a java class by looking up the hashtable > of all java class names in the classpath, and importing internally as > appropriate in the PythonInterpreter. > We can implement that manually ourselves but I understand it may be > redundant since most of the required elements (the java classes hastable > for example) may exist already within jython. Further, I support the > view that the "import" statements are a compiler convenience, not truly > essential to the writing of any python script, and thus the importing > functionality should be part of the interpreter. I doubt this is a generally adoptable scheme for jython. Consider the following scenario: you have a jar containing org.foo.Bar Now autoimporting org.foo when a Bar-object is created works - until you add a package org.baz, also with a Bar-class in it, to the classpath. And then all of the sudden your program won't work anymore. Better use a modified start-script or setup the interpreter accordingly, for a specific environment. That should be easy enough, and your users won't have to worry anymore. Regards, Diez |
From: Oti <oh...@gm...> - 2005-10-31 08:08:18
|
On 10/31/05, Diez B. Roggisch <de...@we...> wrote: > > Our use of jython is to script the image manipulation package ImageJ ( > > http://rsb.info.nih.gov/ij , > > http://www.pensament.net/java/other_plugins.html#jython ). > > It would be very convenient for our non-programmer users to avoid the > > "import" statements when they have to do with java classes, i.e. to hav= e > > jython check automatically for a java class by looking up the hashtable > > of all java class names in the classpath, and importing internally as > > appropriate in the PythonInterpreter. > > We can implement that manually ourselves but I understand it may be > > redundant since most of the required elements (the java classes hastabl= e > > for example) may exist already within jython. Further, I support the > > view that the "import" statements are a compiler convenience, not truly > > essential to the writing of any python script, and thus the importing > > functionality should be part of the interpreter. > > I doubt this is a generally adoptable scheme for jython. Consider the > following scenario: you have a jar containing > > org.foo.Bar > > Now autoimporting org.foo when a Bar-object is created works - until you > add a package org.baz, also with a Bar-class in it, to the classpath. > And then all of the sudden your program won't work anymore. > > Better use a modified start-script or setup the interpreter accordingly, > for a specific environment. That should be easy enough, and your users > won't have to worry anymore. > > Regards, > > Diez I fully agree with Diez: imports should be as explicit as possible, to avoid redundancy. Oti. |