| msg12972 - (view) |
Author: Guido van Rossum (gvanrossum) *  |
Date: 2002-10-28 17:33 |
| Now that we're trying to remove the difference between int and long, it seems fair that int() of a very long decimal string should return a long rather than raising ValueError. |
|
|
| msg12973 - (view) |
Author: Walter Dörwald (doerwalter) * |
Date: 2002-11-06 14:27 |
| Logged In: YES user_id=89016 How about the following patch (diff.txt): In addition to creating longs when necessary, it fixes the problem of the fixed 512 char unicode conversion buffer. What should we do about int(1e200)? |
|
|
| msg12974 - (view) |
Author: Guido van Rossum (gvanrossum) * |
Date: 2002-11-06 16:00 |
| Logged In: YES user_id=6380 If it works, check it in. |
|
|
| msg12975 - (view) |
Author: Walter Dörwald (doerwalter) * |
Date: 2002-11-06 16:17 |
| Logged In: YES user_id=89016 Checked in as: Lib/test/test_b1.py 1.56 Objects/intobject.c 2.94 Objects/longobject.c 1.144 Should I open a seperate bug report for the int(1e200) case? |
|
|
| msg12976 - (view) |
Author: Guido van Rossum (gvanrossum) * |
Date: 2002-11-06 18:33 |
| Logged In: YES user_id=6380 int(1e200) is a separate case. If you know how to fix it, just add a patch here. If you want to put it off, best create a new bug report for it. |
|
|
| msg12977 - (view) |
Author: Walter Dörwald (doerwalter) * |
Date: 2002-11-07 18:48 |
| Logged In: YES user_id=89016 The current fix for the int("...") case might be problematic, as now PyInt_FromString() might return a long object, which breaks the C API. Maybe we should have a two versions of PyInt_FromString(): PyInteger_FromString() that might return int or long and PyInt_FromString which always returns int (or raises an overflow exception). I'll open a separate bug report for the int(1e200) case. |
|
|
| msg12978 - (view) |
Author: Guido van Rossum (gvanrossum) * |
Date: 2002-11-07 22:07 |
| Logged In: YES user_id=6380 Well, there are no docs for PyInt_FromString()... :-( Can you grep the source for uses of it and see if there are any places where the result is accessessed as an PyInt_Object? (I don't expect you'll find any, but who knows.) |
|
|
| msg12979 - (view) |
Author: Walter Dörwald (doerwalter) * |
Date: 2002-11-07 22:26 |
| Logged In: YES user_id=89016 PyInt_FromString is used in abstract.c::int_from_string, which is used in PyNumber_Int, which is documented to return "an integer object". Furthermore Modules/selectmodule.c calls PyNumber_Int immediately followed by PyInt_AS_LONG. Other uses of PyInt_FromString seem to be harmless, as they occur only in intobject.c::int_new (and in PyInt_FromUnicode of course). Other uses of PyNumber_Int are in intobject.c::int_new (this should again be harmless) and in weakrefobject.c (I really don't know what happens here). |
|
|
| msg12980 - (view) |
Author: Guido van Rossum (gvanrossum) * |
Date: 2002-11-07 22:37 |
| Logged In: YES user_id=6380 PyNumber_Int() is pretty much a C wrapper around the int() builtin, so I think it should okay if that returns something else. But that means that selectmodule is broken. Can you fix it? (I think it's use of PyNumber_Check() is also wrong, but maybe that's a separate issue). What's going on it weakrefobject.c is fine. It's really too bad that PyNumber_Int contains so many special cases; these should ideally be done via the tp_int slot of the various types... |
|
|
| msg12981 - (view) |
Author: Walter Dörwald (doerwalter) * |
Date: 2002-11-07 23:03 |
| Logged In: YES user_id=89016 The attached patch diffselect.txt should fix the select module. I'm not so sure, whether the check should be PyInt_Check or PyInt_CheckExact. What should be used instead of the PyNumber_Check() call? |
|
|
| msg12982 - (view) |
Author: Guido van Rossum (gvanrossum) * |
Date: 2002-11-08 01:09 |
| Logged In: YES user_id=6380 No, that's not right. ;-( One could pass 1L and that should work. There's really no reason to use the macro; use PyInt_AsLong() instead and that will do the right thing for a long. |
|
|
| msg12983 - (view) |
Author: Guido van Rossum (gvanrossum) * |
Date: 2002-11-08 01:33 |
| Logged In: YES user_id=6380 No, that's not right. ;-( One could pass 1L and that should work. There's really no reason to use the macro; use PyInt_AsLong() instead and that will do the right thing for a long. |
|
|
| msg12984 - (view) |
Author: Walter Dörwald (doerwalter) * |
Date: 2002-11-12 11:45 |
| Logged In: YES user_id=89016 OK, checked in as: Modules/selectmodule.c 2.71 But this only works as long as the nb_int slot really returns ints, as PyInt_AsLong() can't handle a nb_int slot that returns long. Can we close the bug now. |
|
|