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 benjamin.peterson, mark.dickinson
Date 2009-01-12.09:15:25
SpamBayes Score 0.015844945
Marked as misclassified No
Message-id <1231751728.93.0.64653478502.issue4910@psf.upfronthosting.co.za>
In-reply-to
Content
Here's a patch against the py3k branch that gets rid of the two existing 
uses of nb_long in the core:

 - in PyNumber_Long, conversion was attempted first using nb_int and
   then using nb_long.  The patch simply removes the nb_long code, so
   int(x) no longer attempts to use the __long__ method for conversion.

 - in Modules/_struct.c, there's a call to nb_long in a function that's
   attempting to turn an arbitrary PyObject into a PyLongObject;  the
   patch replaces this with nb_int (and updates an error message).

 - In Lib/test/test_long.py, __long__ has been replaced with __int__
   in a test that __int__/__long__ takes precedence over __trunc__
   for conversion to int.

With this patch, all tests pass on my (OS X 10.5/Intel) machine.
(Except test_socket, but I'm 97.2% certain that's unrelated.)

If someone can review this quickly I'll move on to the next patch towards 
removing nb_long.  (My issue #1717 experience suggests that it ought to be 
easier to effect the removal via a series of 3 or 4 short, easy-to-review 
patches with clear intent than via one bigger, more confused patch.)

I think it would be good if nb_long could be altered before 3.0.1.

Benjamin, do you have time to take a look?
History
Date User Action Args
2009-01-12 09:15:29mark.dickinsonsetrecipients: + mark.dickinson, benjamin.peterson
2009-01-12 09:15:28mark.dickinsonsetmessageid: <1231751728.93.0.64653478502.issue4910@psf.upfronthosting.co.za>
2009-01-12 09:15:28mark.dickinsonlinkissue4910 messages
2009-01-12 09:15:26mark.dickinsoncreate