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: Numeric Literal Anomoly
Type: Stage:
Components: Interpreter Core Versions:
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: tim.peters Nosy List: nobody, ottojas, tim.peters
Priority: normal Keywords:

Created on 2002-06-19 23:45 by ottojas, last changed 2022-04-10 16:05 by admin. This issue is now closed.

Messages (4)
msg11275 - (view) Author: Otto J. A. Smith (ottojas) Date: 2002-06-19 23:45
I hope I am not beating a dead horse.  This might have 
been dealt with in the past, although I failed to find any 
reference to it in a search.

A string representation of a numeric literal is evaluated
differently by "int" and "string.atoi" than by "eval".  The 
functions "int" and "string.atoi" treat the leading zero as
a leading zero in a decimal numeric literal, while "eval" 
treats it as an indication of the literal representing an octal 
value.

Consider the string "077"

>>> 0077
63
>>> eval('077')
63
>>> int('0077')
77
>>> string.atoi("0077")
77

It is probably not possible to change the behavior of "int"
or "string.atoi" due to historic reasons.  I would suggest 
adding a method to the string class that does conversions
from hex and octal string literals correctly.

This may seem like a minor problem but should be done for
the following reasons.

1.  Python is a remarkably regular language and my 
favorite for that reason among others.  The current 
behavior deviates from what one might rationally expect 
and is a blemish (although minor) on an otherwise beutiful 
language.

2.  The only quick way to evaluate a hex or octal numeric 
constant that comes from an outside source, such as the 
web, is with "eval".  This poses security risks.  The use of 
custom programs and/or safe-eval seems like overkill and 
one would expect a builti n safe way to convert from any 
string representing a numeric literal to the internal 
representation.

One would expect the functions "oct" and "int" to allow 
conversions back and forth.   Here is what really happens.

>>> oct(77)
'0115'
>>> int(oct(77))
115
>>> oct(int(oct(77)))
'0163'
>>> int(oct(int(oct(77))))
163
>>> oct(int(oct(int(oct(77)))))
'0243'
>>> int(oct(int(oct(int(oct(77))))))
243
>>> oct(int(oct(int(oct(int(oct(77)))))))
'0363'

Although the above is intriguing, it is not really a 
language feature, nor does it generate errors as would
occur with the use of "hex" instead of "oct".

I would suggest the addition of a new method with a new 
name. (maybe "aint") to the string class., a method that 
would evaluate all the forms of integer numeric literals
with the same behavior as "eval".

Regards
Otto

msg11276 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2002-06-20 00:12
Logged In: YES 
user_id=31435

Read the docs for the int() function.  Is there something you 
want that you can't already do by passing int an optional 
base argument of 0?:

>>> int('077', 0)
63
>>> int('0x77', 0)
119
>>> int('77', 0)
77
>>>
msg11277 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2002-06-24 02:18
Logged In: YES 
user_id=31435

Closed for lack of requested followup.  The int() and long() 
functions already do everything requested here, and more.
msg11278 - (view) Author: Nobody/Anonymous (nobody) Date: 2002-06-24 04:31
Logged In: NO 

You are right.
Boy do I feel stupid right now.

Regards
Otto
History
Date User Action Args
2022-04-10 16:05:26adminsetgithub: 36772
2002-06-19 23:45:31ottojascreate