Message11801

Hmm ... reading Kane's work-around makes me want to break it some more.

>>> b1 = BigInteger.valueOf(9999)
>>> b2 = BigInteger("9999")
>>> type(b1)
<type 'long'>
>>> type(b2)
<type 'java.math.BigInteger'>
>>> b1+1
10000L
>>> b2+1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'java.math.BigInteger' and 'int'
>>> b1==b2
False

This surely isn't what we intended in #2090. If we intend BigInteger to mix arithmetically with Python native types at all, we ought to accept it everywhere a long would be ok. And yet, when a Java type has useful instance methods, you'd prefer not to conceal them. BigInteger(n).abs() is not very compelling, but how about BigInteger(n).isProbablePrime(m), for example?

I think we may be coercing in the wrong place: surely a BigInteger had better keep its unique character until it meets an operator that just needs its long value?

Setting this to high because it raises architectural questions for which I feel we ought to have an answer. Maybe we do.