Jython

It's at 4pm.

Looking forward to seeing you there!

Oti.

On Mon, Aug 30, 2010 at 1:32 PM, Josh Juneau <juneau001@...> wrote:
> A Jython BoF has been scheduled for JavaOne.
>
> Where:  JavaOne Unconference - Hotel Parc 55
> Floor/Room:  2nd Floor in the Ashbury Room
> When: Wednesday, September 22nd.
>
> For more information about the unconference, please visit the site at
> http://wikis.sun.com/display/JavaOne/Unconferences+at+JavaOne+and+Oracle+Develop+2010
>
> Thanks, hope to see you there!
>
> Josh Juneau
> juneau001@...
> http://jj-blogger.blogspot.com
> http://www.jythonpodcast.com
> Twitter ID:  javajuneau
>
> ------------------------------------------------------------------------------
> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
> Be part of this innovative community and reach millions of netbook users
> worldwide. Take advantage of special opportunities to increase revenue and
> speed time-to-market. Join now, and jumpstart your future.
> http://p.sf.net/sfu/intel-atom-d2d
> _______________________________________________
> Jython-users mailing list
> Jython-users@...
> https://lists.sourceforge.net/lists/listinfo/jython-users
>
>

Did you make sure that you deployed the "stand-alone" jython.jar into Maven, instead of the standard jython.jar that is installed by default? The stand-alone jython.jar includes the standard library, including the re module, in the jar file, whereas the standard jython.jar gets the standard Python library from an external directory.

I don't know why this would affect Maven but not your framework. Perhaps your framework was using the standard jython.jar from its installed location, and therefore jython.jar was able to find the standard library directory relative to its own location. That would not work if you ever moved jython.jar somewhere else.

David H

From: Peter Lauri [mailto:peter.lauri.ext@...]
Sent: Wednesday, August 25, 2010 12:18 PM
To: jython-users@...
Subject: [Jython-users] Problems when running jython in ScriptEngine with Maven2

Hi,

We have deployed the jython 2.5.1 jar file that we have created at installation. We have a small framework where the users can write jython code. However, when I was just adding the jython.jar to build path as external library all was working well.

After that we added that jar file to our local maven repository, then we start to get problems. It cannot find the "re" package. Here is the complete error output. It seems like I need to specify where the modules are located, but how to do that for the script engine?

Any help or hint would be happily received.

/Peter


--------


2010-08-25 19:09:55,223 2072 ERROR (main) PythonParser.parse:91 - Error while running the code:
# for regular expressions
import re

match = re.search('a', "qwedas")

javax.script.ScriptException: ImportError: No module named re in <script> at line number 2
    at org.python.jsr223.PyScriptEngine.scriptException(PyScriptEngine.java:182)
    at org.python.jsr223.PyScriptEngine.eval(PyScriptEngine.java:43)
    at org.python.jsr223.PyScriptEngine.eval(PyScriptEngine.java:33)
    at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:247)
    at com.nsn.pc.rebus.parser.impl.python.PythonParser.parse(PythonParser.java:88)
    at com.nsn.pc.rebus.parser.impl.python.PythonParserTest.simple(PythonParserTest.java:39)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
    at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
    at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
    at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
    at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
    at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
    at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
    at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
    at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
    at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
    at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
    at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)
Caused by: Traceback (most recent call last):
  File "<script>", line 2, in <module>
ImportError: No module named re

    at org.python.core.PyException.fillInStackTrace(PyException.java:70)
    at java.lang.Throwable.<init>(Throwable.java:181)
    at java.lang.Exception.<init>(Exception.java:29)
    at java.lang.RuntimeException.<init>(RuntimeException.java:32)
    at org.python.core.PyException.<init>(PyException.java:46)
    at org.python.core.PyException.<init>(PyException.java:43)
    at org.python.core.PyException.<init>(PyException.java:61)
    at org.python.core.Py.ImportError(Py.java:264)
    at org.python.core.imp.import_first(imp.java:672)
    at org.python.core.imp.import_name(imp.java:756)
    at org.python.core.imp.importName(imp.java:806)
    at org.python.core.ImportFunction.__call__(__builtin__.java:1232)
    at org.python.core.PyObject.__call__(PyObject.java:367)
    at org.python.core.__builtin__.__import__(__builtin__.java:1202)
    at org.python.core.__builtin__.__import__(__builtin__.java:1185)
    at org.python.core.imp.importOne(imp.java:817)
    at org.python.pycode._pyx0.f$0(<script>:6)
    at org.python.pycode._pyx0.call_function(<script>)
    at org.python.core.PyTableCode.call(PyTableCode.java:165)
    at org.python.core.PyCode.call(PyCode.java:18)
    at org.python.core.Py.runCode(Py.java:1204)
    at org.python.core.__builtin__.eval(__builtin__.java:504)
    at org.python.util.PythonInterpreter.eval(PythonInterpreter.java:164)
    at org.python.jsr223.PyScriptEngine.eval(PyScriptEngine.java:41)
    ... 30 more

Thanks, you made my day complete :) It worked like a charm. I installed
again with the standalone option and then deployed to maven repo, and now it
all works soooooo nice :) Thanks.


On 2010-08-25 20.46, "ext David Handy" <David.Handy@...> wrote:

> Did you make sure that you deployed the ³stand-alone² jython.jar into Maven,
> instead of the standard jython.jar that is installed by default? The
> stand-alone jython.jar includes the standard library, including the re module,
> in the jar file, whereas the standard jython.jar gets the standard Python
> library from an external directory.
>  
> I don¹t know why this would affect Maven but not your framework. Perhaps your
> framework was using the standard jython.jar from its installed location, and
> therefore jython.jar was able to find the standard library directory relative
> to its own location. That would not work if you ever moved jython.jar
> somewhere else.
>  
> David H
>  
> 
> From: Peter Lauri [mailto:peter.lauri.ext@...]
> Sent: Wednesday, August 25, 2010 12:18 PM
> To: jython-users@...
> Subject: [Jython-users] Problems when running jython in ScriptEngine with
> Maven2
>  
> Hi,
> 
> We have deployed the jython 2.5.1 jar file that we have created at
> installation. We have a small framework where the users can write jython code.
> However, when I was just adding the jython.jar to build path as external
> library all was working well.
> 
> After that we added that jar file to our local maven repository, then we start
> to get problems. It cannot find the ³re² package. Here is the complete error
> output. It seems like I need to specify where the modules are located, but how
> to do that for the script engine?
> 
> Any help or hint would be happily received.
> 
> /Peter
> 
> 
> --------
> 
> 
> 2010-08-25 19:09:55,223 2072 ERROR (main) PythonParser.parse:91 - Error while
> running the code:
> # for regular expressions
> import re
> 
> match = re.search(Œa¹, ³qwedas²)
> 
> javax.script.ScriptException: ImportError: No module named re in <script> at
> line number 2
>     at 
> org.python.jsr223.PyScriptEngine.scriptException(PyScriptEngine.java:182)
>     at org.python.jsr223.PyScriptEngine.eval(PyScriptEngine.java:43)
>     at org.python.jsr223.PyScriptEngine.eval(PyScriptEngine.java:33)
>     at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:247)
>     at 
> com.nsn.pc.rebus.parser.impl.python.PythonParser.parse(PythonParser.java:88)
>     at 
> com.nsn.pc.rebus.parser.impl.python.PythonParserTest.simple(PythonParserTest.j
> ava:39)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>     at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.j
> ava:25)
>     at java.lang.reflect.Method.invoke(Method.java:597)
>     at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.ja
> va:44)
>     at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.jav
> a:15)
>     at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java
> :41)
>     at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:
> 20)
>     at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:
> 76)
>     at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:
> 50)
>     at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
>     at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
>     at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
>     at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
>     at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
>     at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
>     at 
> org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
>     at 
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(Abst
> ractDirectoryTestSuite.java:140)
>     at 
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDir
> ectoryTestSuite.java:127)
>     at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>     at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.j
> ava:25)
>     at java.lang.reflect.Method.invoke(Method.java:597)
>     at 
> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBoo
> ter.java:345)
>     at 
> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)
> Caused by: Traceback (most recent call last):
>   File "<script>", line 2, in <module>
> ImportError: No module named re
> 
>     at org.python.core.PyException.fillInStackTrace(PyException.java:70)
>     at java.lang.Throwable.<init>(Throwable.java:181)
>     at java.lang.Exception.<init>(Exception.java:29)
>     at java.lang.RuntimeException.<init>(RuntimeException.java:32)
>     at org.python.core.PyException.<init>(PyException.java:46)
>     at org.python.core.PyException.<init>(PyException.java:43)
>     at org.python.core.PyException.<init>(PyException.java:61)
>     at org.python.core.Py.ImportError(Py.java:264)
>     at org.python.core.imp.import_first(imp.java:672)
>     at org.python.core.imp.import_name(imp.java:756)
>     at org.python.core.imp.importName(imp.java:806)
>     at org.python.core.ImportFunction.__call__(__builtin__.java:1232)
>     at org.python.core.PyObject.__call__(PyObject.java:367)
>     at org.python.core.__builtin__.__import__(__builtin__.java:1202)
>     at org.python.core.__builtin__.__import__(__builtin__.java:1185)
>     at org.python.core.imp.importOne(imp.java:817)
>     at org.python.pycode._pyx0.f$0(<script>:6)
>     at org.python.pycode._pyx0.call_function(<script>)
>     at org.python.core.PyTableCode.call(PyTableCode.java:165)
>     at org.python.core.PyCode.call(PyCode.java:18)
>     at org.python.core.Py.runCode(Py.java:1204)
>     at org.python.core.__builtin__.eval(__builtin__.java:504)
>     at org.python.util.PythonInterpreter.eval(PythonInterpreter.java:164)
>     at org.python.jsr223.PyScriptEngine.eval(PyScriptEngine.java:41)
>     ... 30 more 
>

Jeff Levesque wrote:
> I've written an API in Python that works in both CPython for scripting 
> and Jython in combination with a GWT front end but I'm having issues 
> with some database results. It seems like something is caching the 
> database results when I'm using Jython. I've read through the 
> ConnectorJ documentation and tried disabling all the caching options I 
> could but it doesn't seem to have made any difference. Is it possible 
> zxJDBC is caching the results or just not passing options I set to 
> JDBC? Any help would be much appreciated.

It is more likely to be the JDBC driver (or dbms) doing the caching than 
zxjdbc (I've not seen zxjdbc do any caching, with defaults).

Can you switch drivers/backends to test that idea out? You could for 
instance be doing repeatable reads (transactions) or some other DBMS 
specific (rather than zxjdbc) thing.

Making a small 10 line script test case is your best bet.

Chris

It will take me a little bit to make a test case for this but the
documentation for execute in PyCursor contains the follow:

    /**
     * Prepare and execute a database operation (query or command).
     * Parameters may be provided as sequence or mapping and will
     * be bound to variables in the operation. Variables are specified
     * in a database-specific notation (see the module's paramstyle
     * attribute for details).
     *
     * A reference to the operation will be retained by the cursor.
     * If the same operation object is passed in again, then the cursor
     * can optimize its behavior. This is most effective for algorithms
     * where the same operation is used, but different parameters are
     * bound to it (many times).
     *
     * For maximum efficiency when reusing an operation, it is best to
     * use the setinputsizes() method to specify the parameter types and
     * sizes ahead of time. It is legal for a parameter to not match the
     * predefined information; the implementation should compensate,
possibly
     * with a loss of efficiency.
     *
     * The parameters may also be specified as list of tuples to e.g. insert
     * multiple rows in a single operation, but this kind of usage is
     * deprecated: executemany() should be used instead.
     *
     * Return values are not defined.
     *
     * @param sql sql string or prepared statement
     * @param params params for a prepared statement
     * @param bindings dictionary of (param index : SQLType binding)
     * @param maxRows integer value of max rows
     */

I was just unable to follow how it works or determine if there was a way to
disable this mechanism.

On Tue, Aug 24, 2010 at 4:52 PM, Chris Clark <Chris.Clark@...> wrote:

> Jeff Levesque wrote:
>
>> I've written an API in Python that works in both CPython for scripting and
>> Jython in combination with a GWT front end but I'm having issues with some
>> database results. It seems like something is caching the database results
>> when I'm using Jython. I've read through the ConnectorJ documentation and
>> tried disabling all the caching options I could but it doesn't seem to have
>> made any difference. Is it possible zxJDBC is caching the results or just
>> not passing options I set to JDBC? Any help would be much appreciated.
>>
>
> It is more likely to be the JDBC driver (or dbms) doing the caching than
> zxjdbc (I've not seen zxjdbc do any caching, with defaults).
>
> Can you switch drivers/backends to test that idea out? You could for
> instance be doing repeatable reads (transactions) or some other DBMS
> specific (rather than zxjdbc) thing.
>
> Making a small 10 line script test case is your best bet.
>
> Chris
>
>

I suspect you are focusing on; "A reference to the operation will be 
retained by the cursor." This is really talking about avoiding 
re-preparing queries or allocating new cursors on each execute. Using 
the same cursor/query against the same table (after a commit of data) 
should return different data. Most (good) CPython DBI drivers do the 
same thing.

I really would be surprised if this was a zxjdbc issue. Maybe have a 
chat with your DBA?

Chris



Jeff Levesque wrote:
> It will take me a little bit to make a test case for this but the 
> documentation for execute in PyCursor contains the follow:
>
>     /**
>      * Prepare and execute a database operation (query or command).
>      * Parameters may be provided as sequence or mapping and will
>      * be bound to variables in the operation. Variables are specified
>      * in a database-specific notation (see the module's paramstyle
>      * attribute for details).
>      *
>      * A reference to the operation will be retained by the cursor.
>      * If the same operation object is passed in again, then the cursor
>      * can optimize its behavior. This is most effective for algorithms
>      * where the same operation is used, but different parameters are
>      * bound to it (many times).
>      *
>      * For maximum efficiency when reusing an operation, it is best to
>      * use the setinputsizes() method to specify the parameter types and
>      * sizes ahead of time. It is legal for a parameter to not match the
>      * predefined information; the implementation should compensate, 
> possibly
>      * with a loss of efficiency.
>      *
>      * The parameters may also be specified as list of tuples to e.g. 
> insert
>      * multiple rows in a single operation, but this kind of usage is
>      * deprecated: executemany() should be used instead.
>      *
>      * Return values are not defined.
>      *
>      * @param sql sql string or prepared statement
>      * @param params params for a prepared statement
>      * @param bindings dictionary of (param index : SQLType binding)
>      * @param maxRows integer value of max rows
>      */
>
> I was just unable to follow how it works or determine if there was a 
> way to disable this mechanism.
>
> On Tue, Aug 24, 2010 at 4:52 PM, Chris Clark <Chris.Clark@... 
> <mailto:Chris.Clark@...>> wrote:
>
>     Jeff Levesque wrote:
>
>         I've written an API in Python that works in both CPython for
>         scripting and Jython in combination with a GWT front end but
>         I'm having issues with some database results. It seems like
>         something is caching the database results when I'm using
>         Jython. I've read through the ConnectorJ documentation and
>         tried disabling all the caching options I could but it doesn't
>         seem to have made any difference. Is it possible zxJDBC is
>         caching the results or just not passing options I set to JDBC?
>         Any help would be much appreciated.
>
>
>     It is more likely to be the JDBC driver (or dbms) doing the
>     caching than zxjdbc (I've not seen zxjdbc do any caching, with
>     defaults).
>
>     Can you switch drivers/backends to test that idea out? You could
>     for instance be doing repeatable reads (transactions) or some
>     other DBMS specific (rather than zxjdbc) thing.
>
>     Making a small 10 line script test case is your best bet.
>
>     Chris
>
>

That would be me. :) So here's how the system is setup. This is basically a
GUI front end to a build environment and the GUI (using GWT+Jython) is just
displaying the information in the database. Somewhere else (on various build
machines) are python scripts that are updating the database. There is no
communication between the python scripts and the GUI front end. So the
pieces of this system aren't actually using the same cursor because all the
pieces have their own database connection.

On Tue, Aug 24, 2010 at 5:44 PM, Chris Clark <Chris.Clark@...> wrote:

>
> I suspect you are focusing on; "A reference to the operation will be
> retained by the cursor." This is really talking about avoiding re-preparing
> queries or allocating new cursors on each execute. Using the same
> cursor/query against the same table (after a commit of data) should return
> different data. Most (good) CPython DBI drivers do the same thing.
>
> I really would be surprised if this was a zxjdbc issue. Maybe have a chat
> with your DBA?
>
> Chris
>
>
>
> Jeff Levesque wrote:
>
>> It will take me a little bit to make a test case for this but the
>> documentation for execute in PyCursor contains the follow:
>>
>>    /**
>>     * Prepare and execute a database operation (query or command).
>>     * Parameters may be provided as sequence or mapping and will
>>     * be bound to variables in the operation. Variables are specified
>>     * in a database-specific notation (see the module's paramstyle
>>     * attribute for details).
>>     *
>>     * A reference to the operation will be retained by the cursor.
>>     * If the same operation object is passed in again, then the cursor
>>     * can optimize its behavior. This is most effective for algorithms
>>     * where the same operation is used, but different parameters are
>>     * bound to it (many times).
>>     *
>>     * For maximum efficiency when reusing an operation, it is best to
>>     * use the setinputsizes() method to specify the parameter types and
>>     * sizes ahead of time. It is legal for a parameter to not match the
>>     * predefined information; the implementation should compensate,
>> possibly
>>     * with a loss of efficiency.
>>     *
>>     * The parameters may also be specified as list of tuples to e.g.
>> insert
>>     * multiple rows in a single operation, but this kind of usage is
>>     * deprecated: executemany() should be used instead.
>>     *
>>     * Return values are not defined.
>>     *
>>     * @param sql sql string or prepared statement
>>     * @param params params for a prepared statement
>>     * @param bindings dictionary of (param index : SQLType binding)
>>     * @param maxRows integer value of max rows
>>     */
>>
>> I was just unable to follow how it works or determine if there was a way
>> to disable this mechanism.
>>
>> On Tue, Aug 24, 2010 at 4:52 PM, Chris Clark <Chris.Clark@...:
>> Chris.Clark@...>> wrote:
>>
>>    Jeff Levesque wrote:
>>
>>        I've written an API in Python that works in both CPython for
>>        scripting and Jython in combination with a GWT front end but
>>        I'm having issues with some database results. It seems like
>>        something is caching the database results when I'm using
>>        Jython. I've read through the ConnectorJ documentation and
>>        tried disabling all the caching options I could but it doesn't
>>        seem to have made any difference. Is it possible zxJDBC is
>>        caching the results or just not passing options I set to JDBC?
>>        Any help would be much appreciated.
>>
>>
>>    It is more likely to be the JDBC driver (or dbms) doing the
>>    caching than zxjdbc (I've not seen zxjdbc do any caching, with
>>    defaults).
>>
>>    Can you switch drivers/backends to test that idea out? You could
>>    for instance be doing repeatable reads (transactions) or some
>>    other DBMS specific (rather than zxjdbc) thing.
>>
>>    Making a small 10 line script test case is your best bet.
>>
>>    Chris
>>
>>
>>
>

Jonathan,

The most likely explanation is that it hasn't been done. The refactoring you
suggest makes sense to me, and should be easy enough to change for 2.5.2
beta 2. I don't know if we can use automatic refactoring tools in this case
because when I looked at the code, we had getValue defined and used in some
places, but it was not consistently used. Regardless it's pretty minimal
code changes in any event.

I've added a bug for this, http://bugs.jython.org/issue1645. Ideally if you
can help me by writing some unit tests we can get this in.

- Jim

On Tue, Aug 17, 2010 at 11:13 AM, Jonathan Feinberg <jdf@...> wrote:

> Folks,
>
> All of PyInteger's operations (div, mult, etc.) access the actual integer
> value of the PyInteger via its getValue() method. That makes it easy for me
> to wrap a Java integer variable and expose it to the interpreter as a
> built-in name, as I do in my processing.py project. For example
>
> class SomeClass {
>     private int myInt = 12;
>     PyObject wrappedInt = new PyInteger(0) {
>         public int getValue() { return myInt; }
>     };
>     // now you can
>     // ((PyStringMap)
> interp.getSystemState().getBuiltins()).__setitem__("pythonName", wrappedInt)
>     // and within your script
>     // print "the answer is %d" % (pythonName + 12)
> }
>
> But PyLong, PyBoolean, and PyFloat do not. Instead, they refer to a private
> "value" member directly. Is there a tactical reason for this? Did someone
> start to apply the PyInteger pattern, but then get bogged down? Did someone
> mean to change PyInteger to be like the others?
>
> Kind regards,
> --
> Jonathan Feinberg  jdf@...  http://MrFeinberg.com/
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Jython-users mailing list
> Jython-users@...
> https://lists.sourceforge.net/lists/listinfo/jython-users
>
>

Jonathan,

I did the refactoring for PyBoolean, PyFloat, and PyLong and committed it in
r7097. (NetBeans has no problem with inconsistent encapsulation of fields.)
We probably want to do this for some other types too, such as collection
types, since it seems like this will support a quite useful usage pattern.

We still need some unit tests that demonstrate that usage, otherwise our
test suite definitely covers such a standard refactoring.

- Jim

On Tue, Aug 17, 2010 at 11:40 AM, Jim Baker <jbaker@...> wrote:

> Jonathan,
>
> The most likely explanation is that it hasn't been done. The refactoring
> you suggest makes sense to me, and should be easy enough to change for 2.5.2
> beta 2. I don't know if we can use automatic refactoring tools in this case
> because when I looked at the code, we had getValue defined and used in some
> places, but it was not consistently used. Regardless it's pretty minimal
> code changes in any event.
>
> I've added a bug for this, http://bugs.jython.org/issue1645. Ideally if
> you can help me by writing some unit tests we can get this in.
>
> - Jim
>
> On Tue, Aug 17, 2010 at 11:13 AM, Jonathan Feinberg <jdf@...> wrote:
>
>> Folks,
>>
>> All of PyInteger's operations (div, mult, etc.) access the actual integer
>> value of the PyInteger via its getValue() method. That makes it easy for me
>> to wrap a Java integer variable and expose it to the interpreter as a
>> built-in name, as I do in my processing.py project. For example
>>
>> class SomeClass {
>>     private int myInt = 12;
>>     PyObject wrappedInt = new PyInteger(0) {
>>         public int getValue() { return myInt; }
>>     };
>>     // now you can
>>     // ((PyStringMap)
>> interp.getSystemState().getBuiltins()).__setitem__("pythonName", wrappedInt)
>>     // and within your script
>>     // print "the answer is %d" % (pythonName + 12)
>> }
>>
>> But PyLong, PyBoolean, and PyFloat do not. Instead, they refer to a
>> private "value" member directly. Is there a tactical reason for this? Did
>> someone start to apply the PyInteger pattern, but then get bogged down? Did
>> someone mean to change PyInteger to be like the others?
>>
>> Kind regards,
>> --
>> Jonathan Feinberg  jdf@...  http://MrFeinberg.com/
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by
>>
>> Make an app they can't live without
>> Enter the BlackBerry Developer Challenge
>> http://p.sf.net/sfu/RIM-dev2dev
>> _______________________________________________
>> Jython-users mailing list
>> Jython-users@...
>> https://lists.sourceforge.net/lists/listinfo/jython-users
>>
>>
>

On Tue, Aug 17, 2010 at 3:34 PM, Jim Baker <jbaker@...> wrote:

> I did the refactoring for PyBoolean, PyFloat, and PyLong and committed it
> in r7097. (NetBeans has no problem with inconsistent encapsulation of
> fields.) We probably want to do this for some other types too, such as
> collection types, since it seems like this will support a quite useful usage
> pattern.
>

+1 NetBeans, +10 Jim Baker!

Would it be possible for PyString as well? I see some sorts of auxilliary
data structures in there, so I wouldn't be surprised if that were less
doable.


> We still need some unit tests that demonstrate that usage, otherwise our
> test suite definitely covers such a standard refactoring.
>

I'd be very happy to help there, but you'll have to have patience with me
while I get up to speed with setting up my workspace to develop, build, and
test Jython. Up until now I've been using the binary. If there's any
documentation on the subject, please send me that way. If not, I've figured
out this kind of thing before.

I'm an Eclipse man, myself, but would install NetBeans if that were the
strongly supported Jython development platform.

Gratefully,
-- 
Jonathan Feinberg  jdf@...  http://MrFeinberg.com/

In article 
<AANLkTi=9ZM5tehKgZu3Yf1tWza2PNVX1d_Yf8nJa1bh5@...>,
 Jonathan Feinberg <jdf@...> wrote:

> I'd be very happy to help there, but you'll have to have patience with me
> while I get up to speed with setting up my workspace to develop, build, and
> test Jython. Up until now I've been using the binary. If there's any
> documentation on the subject, please send me that way. If not, I've figured
> out this kind of thing before.

<http://wiki.python.org/jython/JythonDeveloperGuide>

Feel free to ask here if you get stuck.
-- 
Nicholas Riley <njriley@...>

On Tue, Aug 17, 2010 at 3:34 PM, Jim Baker <jbaker@...> wrote:

> I did the refactoring for PyBoolean, PyFloat, and PyLong and committed it
> in r7097. (NetBeans has no problem with inconsistent encapsulation of
> fields.) We probably want to do this for some other types too, such as
> collection types, since it seems like this will support a quite useful usage
> pattern.
>
> We still need some unit tests that demonstrate that usage, otherwise our
> test suite definitely covers such a standard refactoring.
>

I submitted a patch that fixes a couple of lingering unencapsulated accesses
to "value ", and adds a good start for unit tests of the three numeric
classes in question.

    http://bugs.jython.org/issue1645
    http://bugs.jython.org/file865/fix_and_test_numeric_accessors.diff

Let me know if it's in the wrong place or otherwise unuseful.
-- 
Jonathan Feinberg  jdf@...  http://MrFeinberg.com/

16.8.2010 13:09, Networked kirjoitti:
> Hi List,
> I tried running jythonc and got an error in org.python.core PathPackageManager.
>
Jythonc was removed completely in 2.5.0.
What are you trying to do with it?
> *sys-package-mgr*: processing new jar,
> '/Development/OtherSDKs/jython2.5a1+/jython-complete.jar'
> *sys-package-mgr*: processing new jar,
> '/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Classes/classes.jar'
> *sys-package-mgr*: processing new jar,
> '/System/Library/Frameworks/JavaVM.framework/Versions/A/Frameworks/JavaRuntimeSupport.framework/Versions/A/Resources/Java/JavaRuntimeSupport.jar'
> *sys-package-mgr*: processing new jar,
> '/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Classes/ui.jar'
> *sys-package-mgr*: processing new jar,
> '/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Classes/jsse.jar'
> *sys-package-mgr*: processing new jar,
> '/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/lib/jce.jar'
> *sys-package-mgr*: processing new jar,
> '/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Classes/charsets.jar'
> *sys-package-mgr*: processing new jar,
> '/System/Library/Java/Extensions/AppleScriptEngine.jar'
> *sys-package-mgr*: processing new jar,
> '/System/Library/Java/Extensions/dns_sd.jar'
> *sys-package-mgr*: processing new jar,
> '/System/Library/Java/Extensions/j3daudio.jar'
> *sys-package-mgr*: processing new jar,
> '/System/Library/Java/Extensions/j3dcore.jar'
> *sys-package-mgr*: processing new jar,
> '/System/Library/Java/Extensions/j3dutils.jar'
> *sys-package-mgr*: processing new jar,
> '/System/Library/Java/Extensions/jai_codec.jar'
> *sys-package-mgr*: processing new jar,
> '/System/Library/Java/Extensions/jai_core.jar'
> *sys-package-mgr*: processing new jar,
> '/System/Library/Java/Extensions/mlibwrapper_jai.jar'
> *sys-package-mgr*: processing new jar,
> '/System/Library/Java/Extensions/MRJToolkit.jar'
> *sys-package-mgr*: processing new jar,
> '/System/Library/Java/Extensions/QTJava.zip'
> *sys-package-mgr*: processing new jar,
> '/System/Library/Java/Extensions/vecmath.jar'
> *sys-package-mgr*: processing new jar,
> '/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/lib/ext/apple_provider.jar'
> *sys-package-mgr*: processing new jar,
> '/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/lib/ext/dnsns.jar'
> *sys-package-mgr*: processing new jar,
> '/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/lib/ext/localedata.jar'
> *sys-package-mgr*: processing new jar,
> '/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/lib/ext/sunjce_provider.jar'
> *sys-package-mgr*: processing new jar,
> '/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/lib/ext/sunpkcs11.jar'
> Traceback (most recent call last):
>    File "/Development/OtherSDKs/jython2.5a1+/Tools/jythonc/jythonc.py",
> line 4, in<module>
>      import main
>    File "/Development/OtherSDKs/jython2.5a1+/Tools/jythonc/main.py",
> line 74, in<module>
>      from compile import Compiler
>    File "/Development/OtherSDKs/jython2.5a1+/Tools/jythonc/compile.py",
> line 7, in<module>
>      from SrcGenCompiler import SrcGenCompiler
>    File "/Development/OtherSDKs/jython2.5a1+/Tools/jythonc/SrcGenCompiler.py",
> line 4, in<module>
>      import ImportName
>    File "/Development/OtherSDKs/jython2.5a1+/Tools/jythonc/ImportName.py",
> line 9, in<module>
>      from util import lookup
>    File "/Development/OtherSDKs/jython2.5a1+/Tools/jythonc/util.py",
> line 35, in<module>
>      from yapm import YaPM
>    File "/Development/OtherSDKs/jython2.5a1+/Tools/jythonc/yapm.py",
> line 10, in<module>
>      from org.python.core import PathPackageManager
> ImportError: cannot import name PathPackageManager
>
>
> Jython: Jython 2.5a1+ (asm:4943:4945, Jul 15 2008, 15:30:04)
> [Java HotSpot(TM) 64-Bit Server VM (Apple Inc.)] on java1.6.0_20
>
> Any help is appreciated. I would assume I'm looking at trying jythonc
> from a different rev?
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Jython-users mailing list
> Jython-users@...
> https://lists.sourceforge.net/lists/listinfo/jython-users

Of course we don't support jythonc. For a variety of reasons, it makes no
sense now, especially since we can readily work around it and eventually
replace it with clamp.

However jythonc still lingers around in the Tools directory in source, even
if it's not copied to builds/installs. This was a big oversight, and I have
put in an issue to track this: http://bugs.jython.org/issue1643. The upshot
is, we will delete this directory from trunk.

I think the reason why we kept around is that the code in there is useful,
in a sandbox way. But since subversion never actually deletes things, we
just need to make it harder to find.

- Jim

2010/8/16 Alex Grönholm <alex.gronholm@...>

>  16.8.2010 13:09, Networked kirjoitti:
> > Hi List,
> > I tried running jythonc and got an error in org.python.core
> PathPackageManager.
> >
> Jythonc was removed completely in 2.5.0.
> What are you trying to do with it?
> > *sys-package-mgr*: processing new jar,
> > '/Development/OtherSDKs/jython2.5a1+/jython-complete.jar'
> > *sys-package-mgr*: processing new jar,
> >
> '/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Classes/classes.jar'
> > *sys-package-mgr*: processing new jar,
> >
> '/System/Library/Frameworks/JavaVM.framework/Versions/A/Frameworks/JavaRuntimeSupport.framework/Versions/A/Resources/Java/JavaRuntimeSupport.jar'
> > *sys-package-mgr*: processing new jar,
> >
> '/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Classes/ui.jar'
> > *sys-package-mgr*: processing new jar,
> >
> '/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Classes/jsse.jar'
> > *sys-package-mgr*: processing new jar,
> >
> '/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/lib/jce.jar'
> > *sys-package-mgr*: processing new jar,
> >
> '/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Classes/charsets.jar'
> > *sys-package-mgr*: processing new jar,
> > '/System/Library/Java/Extensions/AppleScriptEngine.jar'
> > *sys-package-mgr*: processing new jar,
> > '/System/Library/Java/Extensions/dns_sd.jar'
> > *sys-package-mgr*: processing new jar,
> > '/System/Library/Java/Extensions/j3daudio.jar'
> > *sys-package-mgr*: processing new jar,
> > '/System/Library/Java/Extensions/j3dcore.jar'
> > *sys-package-mgr*: processing new jar,
> > '/System/Library/Java/Extensions/j3dutils.jar'
> > *sys-package-mgr*: processing new jar,
> > '/System/Library/Java/Extensions/jai_codec.jar'
> > *sys-package-mgr*: processing new jar,
> > '/System/Library/Java/Extensions/jai_core.jar'
> > *sys-package-mgr*: processing new jar,
> > '/System/Library/Java/Extensions/mlibwrapper_jai.jar'
> > *sys-package-mgr*: processing new jar,
> > '/System/Library/Java/Extensions/MRJToolkit.jar'
> > *sys-package-mgr*: processing new jar,
> > '/System/Library/Java/Extensions/QTJava.zip'
> > *sys-package-mgr*: processing new jar,
> > '/System/Library/Java/Extensions/vecmath.jar'
> > *sys-package-mgr*: processing new jar,
> >
> '/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/lib/ext/apple_provider.jar'
> > *sys-package-mgr*: processing new jar,
> >
> '/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/lib/ext/dnsns.jar'
> > *sys-package-mgr*: processing new jar,
> >
> '/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/lib/ext/localedata.jar'
> > *sys-package-mgr*: processing new jar,
> >
> '/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/lib/ext/sunjce_provider.jar'
> > *sys-package-mgr*: processing new jar,
> >
> '/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/lib/ext/sunpkcs11.jar'
> > Traceback (most recent call last):
> >    File "/Development/OtherSDKs/jython2.5a1+/Tools/jythonc/jythonc.py",
> > line 4, in<module>
> >      import main
> >    File "/Development/OtherSDKs/jython2.5a1+/Tools/jythonc/main.py",
> > line 74, in<module>
> >      from compile import Compiler
> >    File "/Development/OtherSDKs/jython2.5a1+/Tools/jythonc/compile.py",
> > line 7, in<module>
> >      from SrcGenCompiler import SrcGenCompiler
> >    File
> "/Development/OtherSDKs/jython2.5a1+/Tools/jythonc/SrcGenCompiler.py",
> > line 4, in<module>
> >      import ImportName
> >    File
> "/Development/OtherSDKs/jython2.5a1+/Tools/jythonc/ImportName.py",
> > line 9, in<module>
> >      from util import lookup
> >    File "/Development/OtherSDKs/jython2.5a1+/Tools/jythonc/util.py",
> > line 35, in<module>
> >      from yapm import YaPM
> >    File "/Development/OtherSDKs/jython2.5a1+/Tools/jythonc/yapm.py",
> > line 10, in<module>
> >      from org.python.core import PathPackageManager
> > ImportError: cannot import name PathPackageManager
> >
> >
> > Jython: Jython 2.5a1+ (asm:4943:4945, Jul 15 2008, 15:30:04)
> > [Java HotSpot(TM) 64-Bit Server VM (Apple Inc.)] on java1.6.0_20
> >
> > Any help is appreciated. I would assume I'm looking at trying jythonc
> > from a different rev?
> >
> >
> ------------------------------------------------------------------------------
> > This SF.net email is sponsored by
> >
> > Make an app they can't live without
> > Enter the BlackBerry Developer Challenge
> > http://p.sf.net/sfu/RIM-dev2dev
> > _______________________________________________
> > Jython-users mailing list
> > Jython-users@...
> > https://lists.sourceforge.net/lists/listinfo/jython-users
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Jython-users mailing list
> Jython-users@...
> https://lists.sourceforge.net/lists/listinfo/jython-users
>