Issue571382
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.
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) * | 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) * | 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:26 | admin | set | github: 36772 |
2002-06-19 23:45:31 | ottojas | create |