Message 188246 - Python tracker

➜

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	skrah
Recipients	Devin Jeanpierre, mark.dickinson, skrah, vstinner
Date	2013-05-01.22:26:24
SpamBayes Score	-1.0
Marked as misclassified	Yes
Message-id	<[email protected]>
In-reply-to	<[email protected]>

Content
Mark Dickinson <[email protected]> wrote: > There's also some cleanup to be done with respect to semantics; I think it's still the case that the various PyLong_FromXXX functions have different behaviours with respect to overflow, __int__, __index__ and the like. If we just blindly map the old functions to the fixed-width versions we're going to end up changing those semantics on some platforms. That could be a problem. It's tempting though, since we'd finally have a uniform behavior for the PyLong_FromXXX functions (#12965). > I'd be quite happy to see fixed-width conversion functions that completely ignore __int__ and __index__, and leave the magic stuff to general PyNumber_... functions. Definitely.

Mark Dickinson <[email protected]> wrote:
> There's also some cleanup to be done with respect to semantics;  I think it's still the case that the various PyLong_FromXXX functions have different behaviours with respect to overflow, __int__, __index__ and the like.  If we just blindly map the old functions to the fixed-width versions we're going to end up changing those semantics on some platforms.

That could be a problem. It's tempting though, since we'd finally have
a uniform behavior for the PyLong_FromXXX functions (#12965).

> I'd be quite happy to see fixed-width conversion functions that *completely ignore* __int__ and __index__, and leave the magic stuff to general PyNumber_... functions.

Definitely.

History
Date	User	Action	Args
2013-05-01 22:26:24	skrah	set	recipients: + skrah, mark.dickinson, vstinner, Devin Jeanpierre
2013-05-01 22:26:24	skrah	link	issue17884 messages
2013-05-01 22:26:24	skrah	create