[Python-bugs-list] [ python-Bugs-629989 ] int("123123123123123123") doesn't work

[noreply@sourceforge.net]

Bugs item #629989, was opened at 2002-10-28 12:33
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=629989&group_id=5470

Category: Type/class unification
Group: Python 2.3
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Walter Dörwald (doerwalter)
>Summary: int("123123123123123123") doesn't work

Initial Comment:
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.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-11-07 20:09

Message:
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.

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2002-11-07 18:03

Message:
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?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-11-07 17:37

Message:
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...


----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2002-11-07 17:26

Message:
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).


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-11-07 17:07

Message:
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.)


----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2002-11-07 13:48

Message:
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.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-11-06 13:33

Message:
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.

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2002-11-06 11:17

Message:
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?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-11-06 11:00

Message:
Logged In: YES 
user_id=6380

If it works, check it in.

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2002-11-06 09:27

Message:
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)?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=629989&group_id=5470