Re: [Jython-users] Unintuitive comparison between long and BigInteger

It's more of a jython-dev discussion, but yes, I suspect that would be 
better.

Johan's test program is different from the Jython prompt in two ways. It 
uses toString() to obtain what it prints, and it wraps a JSR-223 
interpreter. The Jython prompt uses a repr() to obtain its result to 
print, and a slightly different interpreter.

The toString() vs. repr() difference accounts for the way the type 
object looks when we evaluate type(a), and a is a long, in Johan's test 
program vs. at the prompt.

The relevant interpreter difference is in the container used as the 
namespace. At the Jython prompt we use a container that holds the 
objects as they are (like a dict). The JSR-223 interpreter uses a 
container that strips the Jython wrapper, when storing objects, and 
wraps a stored "naked" Java type into its corresponding Jython type. 
Hence (since the patch) BigInteger gets wrapped to PyLong, whether it 
started that way or not. type(10L) directly will give you a different 
result from a = 10L followed by type(a) because the value is stored in 
the namespace while the 10L is just on the stack.

I expect this unwrapping and wrapping is done to make namespaces more 
friendly to Java code. I suspect the wrapping and unwrapping to be a 
harmful divergence between the JSR-223 and regular interpreters. I'm not 
sure what the ramifications would be of doing it differently. 
(Presumably the namespace would have the "normal" implementation and the 
unwrapping and wrapping would have to go on between it and Java.) This 
seemed like a big change and to deserve more thought. But thanks for 
raising it.

I was content to apply the patch because the class adapter from 
BigInteger to PyLong ought anyway to exist in Jython. The JSR-223 
interpreter, as designed, naturally uses it, which is at least 
consistent with other types.

Jeff Allen

On 30/10/2014 18:07, Curtis Rueden wrote:
> Hi everyone,
>
> Jeff Allen wrote:
> > We now have, using Raphael's patch and an embedded JSR-233 script 
> engine:
> > TEST >>> from java.math import BigInteger
> > TEST >>> a = BigInteger('10')
> > TEST >>> type(a)
> > class org.python.core.PyLong
>
> Apologies if I'm being naive, but wouldn't the ultimately desired 
> behavior be as follows?
>
> TEST >>> from java.math import BigInteger
> TEST >>> a = BigInteger('10')
> TEST >>> type(a)
> class java.math.BigInteger
> TEST >>> a = 10L
> TEST >>> type(a)
> class org.python.core.PyLong
>
> Otherwise, intuitively there might be problems in the "other 
> direction" with legitimate BigIntegers being misinterpreted somehow, 
> right?
>
> The SciJava Jython script engine I mentioned earlier has the following 
> behavior:
>
> from java.math import BigInteger
> a = BigInteger('10')
> print(type(a))
> a = 10L
> print(type(a))
>
> Produces:
>
> <type 'java.math.BigInteger'>
> <type 'long'>
>
> Regards,
> Curtis
>


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