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, 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 <> wrote:

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

This email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
Jython-users mailing list