Message11801

Author jeff.allen
Recipients alex.gronholm, jeff.allen, kaneg, zyasoft
Date 2018-03-14.21:01:00
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1521061261.85.0.467229070634.issue2382@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2018-03-14 21:01:01jeff.allensetmessageid: <1521061261.85.0.467229070634.issue2382@psf.upfronthosting.co.za>
2018-03-14 21:01:01jeff.allensetrecipients: + jeff.allen, zyasoft, alex.gronholm, kaneg
2018-03-14 21:01:01jeff.allenlinkissue2382 messages
2018-03-14 21:01:00jeff.allencreate