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 benjamin.peterson
Recipients benjamin.peterson, mark.dickinson
Date 2009-01-15.17:56:59
SpamBayes Score 0.0002847281
Marked as misclassified No
Message-id <1afaf6160901150956h28d5bc8ehbccd85fefd7d72b2@mail.gmail.com>
In-reply-to <1232038096.18.0.856118615051.issue4910@psf.upfronthosting.co.za>
Content
On Thu, Jan 15, 2009 at 10:48 AM, Mark Dickinson <report@bugs.python.org> wrote:
>
> Mark Dickinson <dickinsm@gmail.com> added the comment:
>
> Thanks, Benjamin!  Checked in in r68553, backported to 3.0 in r68556.
>
> Here's the second patch, which fixes almost all remaining uses of nb_long
> but stops short of actually removing/renaming the nb_long slot.
>
> Notes:
>
> (1) I haven't tested the change to PC/winreg.c

This looks correct. In fact, I don't really see the point of having
PyHKEY_unaryFailureFunc since a TypeError will automatically be raised
if the slot is NULL, but that is certainly another issue.

>
> (2) The Modules/_struct.c change does introduce a change in behaviour:
> for example, before the patch,
>
> struct.pack('q', decimal.Decimal(1))
>
> raises struct.error.  After the patch, the packing succeeds.  I *think*
> the patched behaviour is probably the right behaviour, since it agrees
> with 2.x, but it's not 100% clear to me what the intentions of the struct
> module are with respect to integer packing of non-integer types.  This is
> probably a question for another issue.

Since Decimal implements __int__ and that's what the struct module is
converting with, I think this is fine.

Overall, the patch looks fine. I wonder if we should mark
PyNumber_Long as deprecated in the docs, though.
History
Date User Action Args
2009-01-15 17:57:01benjamin.petersonsetrecipients: + benjamin.peterson, mark.dickinson
2009-01-15 17:57:00benjamin.petersonlinkissue4910 messages
2009-01-15 17:56:59benjamin.petersoncreate