Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment:
Applied as r66332
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3777
___
___
Python-bugs-list mailing
Skip Montanaro [EMAIL PROTECTED] added the comment:
Just a quick nit, but it seems to me that since 2.6 still actually
distinguishes between longs and ints that the two error messages in
PyLong_FromFloat should mention long instead of integer.
Skip
--
nosy: +skip.montanaro
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment:
I suppose you meant PyLong_FromDouble()? I think the messages talk about
abstract numbers, not a specific python type: infinity/NaN cannot be
converted to an integral value.
--
resolution: - fixed
status: open - closed
Skip Montanaro [EMAIL PROTECTED] added the comment:
Amaury I suppose you meant PyLong_FromDouble()?
Yes, sorry.
Amaury I think the messages talk about abstract numbers, not a specific
Amaury python type: infinity/NaN cannot be converted to an integral
Amaury value.
Well, 2.5
Benjamin Peterson [EMAIL PROTECTED] added the comment:
In the meantime, Amaury, you patch is good.
--
keywords: -needs review
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3777
___
Benjamin Peterson [EMAIL PROTECTED] added the comment:
Jeffery, you made this change in r59671. Can you comment?
--
nosy: +benjamin.peterson, jyasskin
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3777
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment:
You are right: long(4.2) used to return a long.
This was changed by the introduction of the float_trunc() function,
which is now used for float.__trunc__, float.__int__ and float.__long__.
OTOH, long() has always been allowed to return
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment:
Here is a patch that restores the float-long conversion. The function
was simply copied from 2.5.
--
keywords: +needs review, patch
Added file: http://bugs.python.org/file11410/float_long.patch
Barry Alan Scott [EMAIL PROTECTED] added the comment:
My concern and yours is that this is not backwards
compatible. I would hate to see random failures
of extensions written using PyCXX because of this.
I'm tempted to says that I'll keep PyCXX 5.x as is for
Python 2.x and leave all the changes
