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.

classification
Title: int('x',radix) puzzle
Type: Stage:
Components: Library (Lib) Versions: Python 2.4
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: azgordo, georg.brandl, rhettinger
Priority: normal Keywords:

Created on 2005-06-05 13:11 by azgordo, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (5)
msg25490 - (view) Author: elgordo (azgordo) Date: 2005-06-05 13:11
I don’t understand the built-in function int(x, radix). Or 
its documentation in the Library Reference section 2.1 – 
Built-In Functions. I’m using Python 2.4.1 on Windows 
XP Pro w/SP2, And I get the following on IDLE:

>>> int(9)
9
>>> int('9')
9
>>> int('9',2)

Traceback (most recent call last):
  File "<pyshell#31>", line 1, in -toplevel-
    int('9',2)
ValueError: invalid literal for int(): 9
>>> int('9',8)

Traceback (most recent call last):
  File "<pyshell#32>", line 1, in -toplevel-
    int('9',8)
ValueError: invalid literal for int(): 9
>>> int('9',10)
9
>>> int('9',16)
9
>>> int('19',16)
25
>>>
msg25491 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2005-06-05 14:08
Logged In: YES 
user_id=1188172

The function is behaving as expected. The radix argument
specifies which base the number system in the string has.
Radix 2 means binary, for example, and radix 16 hexadecimal.
From that, it is clear that '9' is an invalid binary or
octal number.

In the future, please direct such questions to the Newsgroup
comp.lang.python.

Closing as Invalid.
msg25492 - (view) Author: elgordo (azgordo) Date: 2005-06-05 14:52
Logged In: YES 
user_id=1291540

OK --- I was confused by the documentation. I'd like to 
propose the following replacement for the documentation:

int([x[, b]])
Converts base b numbers specified by the inputs to their 
decimal integer equivalents. When the base b is absent x 
may be either (i) the string representation of a possibly 
signed decimal integer (possibly embedded in whitespace), 
or (ii) a possibly signed decimal integer or floating point 
number (floating point numbers are truncated towards zero). If 
the base b is present and non-zero, it must be an integer in 
the range [2, 36] and x must be the possibly signed string 
representation of an integer in base b notation. When x is a 
string and the base b is zero, the base actually used is 
guessed by interpreting the string x in the same way as for 
integer literals.  When b is present then (i) if  x is not a string 
a TypeError is raised, and (ii) if the string x does not 
represent an integer then a ValueError is raised. Returns 0 if 
no arguments are given.
msg25493 - (view) Author: elgordo (azgordo) Date: 2005-06-05 14:54
Logged In: YES 
user_id=1291540

OK --- I was confused by the documentation. I'd like to 
propose the following replacement for the documentation:

int([x[, b]])
Converts base b numbers specified by the inputs to their 
decimal integer equivalents. When the base b is absent x 
may be either (i) the string representation of a possibly 
signed decimal integer (possibly embedded in whitespace), 
or (ii) a possibly signed decimal integer or floating point 
number (floating point numbers are truncated towards zero). If 
the base b is present and non-zero, it must be an integer in 
the range [2, 36] and x must be the possibly signed string 
representation of an integer in base b notation. When x is a 
string and the base b is zero, the base actually used is 
guessed by interpreting the string x in the same way as for 
integer literals.  When b is present then (i) if  x is not a string 
a TypeError is raised, and (ii) if the string x does not 
represent an integer then a ValueError is raised. Returns 0 if 
no arguments are given.
msg25494 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2005-06-05 21:52
Logged In: YES 
user_id=80475

I find the current wording to be preferable.   

At some point, adding more words and excessively detailed
doc results in docs that are less readable and less
communicative.
History
Date User Action Args
2022-04-11 14:56:11adminsetgithub: 42056
2005-06-05 13:11:51azgordocreate