[Python-bugs-list] [ python-Bugs-571382 ] Numeric Literal Anomoly

[noreply@sourceforge.net]

Bugs item #571382, was opened at 2002-06-19 16:45
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571382&group_id=5470

Category: Python Interpreter Core
Group: Not a Bug
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Otto J. A. Smith (ottojas)
Assigned to: Tim Peters (tim_one)
Summary: Numeric Literal Anomoly

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



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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-06-23 21:31

Message:
Logged In: NO 

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

Regards
Otto

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

Comment By: Tim Peters (tim_one)
Date: 2002-06-23 19:18

Message:
Logged In: YES 
user_id=31435

Closed for lack of requested followup.  The int() and long() 
functions already do everything requested here, and more.

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

Comment By: Tim Peters (tim_one)
Date: 2002-06-19 17:12

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

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

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