This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author mark.dickinson
Recipients debedb, mark.dickinson, rhettinger, terry.reedy, vstinner
Date 2009-03-28.04:22:03
SpamBayes Score 1.7208457e-15
Marked as misclassified No
Message-id <1238214126.8.0.75073675188.issue5377@psf.upfronthosting.co.za>
In-reply-to
Content
Thanks for the patch, Victor.  I think this is the right thing to do, 
though I'm still not sure why anyone would care about getting longs 
instead of ints back from int(x).

Comments and questions:

(0) Please could you add some tests!
(1) Shouldn't the first line you added include a check for res == NULL?  
(2) It looks as though the patched code ends up calling PyLong_Check twice 
when __int__ returns a long.  Can you find a clear rewrite that avoids 
this duplication?

By the way, I realized after posting my last comment that the issue with 
Fraction has nothing to do with extreme int values.  For example, with the 
current trunk (not including Victor's patch):

>>> int(Fraction(2L))
2L
>>> int(int(Fraction(2L)))
2

I don't think should be considered a bug in Fraction---I think Victor's 
solution of making the int() machinery always return int when possible is 
the right one here.  The need to call int(int(x)) if you *really* want an 
int seems a little ugly.
History
Date User Action Args
2009-03-28 04:22:07mark.dickinsonsetrecipients: + mark.dickinson, rhettinger, terry.reedy, vstinner, debedb
2009-03-28 04:22:06mark.dickinsonsetmessageid: <1238214126.8.0.75073675188.issue5377@psf.upfronthosting.co.za>
2009-03-28 04:22:05mark.dickinsonlinkissue5377 messages
2009-03-28 04:22:03mark.dickinsoncreate