What do you think about letting the `int` constructor automatically understand the number type without specifying base if given a prefix, so int('0x3414fa') would immediately work without specifying a base of 16?
On 02/06/2014 11:24 AM, Ram Rachum wrote:
What do you think about letting the `int` constructor automatically understand the number type without specifying base if given a prefix, so int('0x3414fa') would immediately work without specifying a base of 16?
Do you mean int(numeral), where numeral is a *variable* string, with a python base prefix? (Else, just type in the constant 0x3414fa ;-) If yes, then I find it a good idea. When int() is used to decode variable numerals, it could/should/would decode all correct python numeral notations. Note that int() also does not decode 'e' postfixes: Python 3.3.2+ (default, Oct 9 2013, 14:50:09) [GCC 4.8.1] on linux Type "help", "copyright", "credits" or "license" for more information.
int(123e2) 12300 int("123e2") Traceback (most recent call last): File "<stdin>", line 1, in <module> ValueError: invalid literal for int() with base 10: '123e2'
But float() does:
float(-1.23e4) -12300.0 float("-1.23e4") -12300.0
! After all, it's just a question of practical notational conventions (we don't use "hundred and twenty-three" or "CXXIII" or "v^^^^^v^^"). Python's own decoding builtins should be consistent with its own choice of notations. d
Yep, that's what I meant :) On Thu, Feb 6, 2014 at 2:28 PM, spir <denis.spir@gmail.com> wrote:
On 02/06/2014 11:24 AM, Ram Rachum wrote:
What do you think about letting the `int` constructor automatically understand the number type without specifying base if given a prefix, so int('0x3414fa') would immediately work without specifying a base of 16?
Do you mean int(numeral), where numeral is a *variable* string, with a python base prefix? (Else, just type in the constant 0x3414fa ;-) If yes, then I find it a good idea. When int() is used to decode variable numerals, it could/should/would decode all correct python numeral notations.
Note that int() also does not decode 'e' postfixes:
Python 3.3.2+ (default, Oct 9 2013, 14:50:09) [GCC 4.8.1] on linux Type "help", "copyright", "credits" or "license" for more information.
int(123e2)
12300
int("123e2")
Traceback (most recent call last): File "<stdin>", line 1, in <module> ValueError: invalid literal for int() with base 10: '123e2'
But float() does:
float(-1.23e4)
-12300.0
float("-1.23e4")
-12300.0
!
After all, it's just a question of practical notational conventions (we don't use "hundred and twenty-three" or "CXXIII" or "v^^^^^v^^"). Python's own decoding builtins should be consistent with its own choice of notations.
d _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
--
--- You received this message because you are subscribed to a topic in the Google Groups "python-ideas" group. To unsubscribe from this topic, visit https://groups.google.com/d/ topic/python-ideas/RKQviWz9BYk/unsubscribe. To unsubscribe from this group and all its topics, send an email to python-ideas+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
For point of reference, other languages are similarly broken (or perhaps they just choose to not guess). Ruby for example exhibits the following behaviour: '0x123'.to_i # => 0 '0x123'.to_i 16 # => 291 '123'.to_i # => 123 And for what it is worth, int has a default parameter base with the value of 10. If you look at the documentation that is present: | int(x, base=10) -> int or long In other words, int is always expecting a base 10 number unless otherwise specified. Guessing at a number's base to save you from having to call int('0x123', 16) is not a good thing. Regarding internal consistency (int vs float), I would guess (but I don't know) that this has to do with how floats are represented typically. But I'll let someone with more specific knowledge of that difference answer that concern. On Thu, Feb 6, 2014 at 6:30 AM, Ram Rachum <ram@rachum.com> wrote:
Yep, that's what I meant :)
On Thu, Feb 6, 2014 at 2:28 PM, spir <denis.spir@gmail.com> wrote:
On 02/06/2014 11:24 AM, Ram Rachum wrote:
What do you think about letting the `int` constructor automatically understand the number type without specifying base if given a prefix, so int('0x3414fa') would immediately work without specifying a base of 16?
Do you mean int(numeral), where numeral is a *variable* string, with a python base prefix? (Else, just type in the constant 0x3414fa ;-) If yes, then I find it a good idea. When int() is used to decode variable numerals, it could/should/would decode all correct python numeral notations.
Note that int() also does not decode 'e' postfixes:
Python 3.3.2+ (default, Oct 9 2013, 14:50:09) [GCC 4.8.1] on linux Type "help", "copyright", "credits" or "license" for more information.
int(123e2)
12300
int("123e2")
Traceback (most recent call last): File "<stdin>", line 1, in <module> ValueError: invalid literal for int() with base 10: '123e2'
But float() does:
float(-1.23e4)
-12300.0
float("-1.23e4")
-12300.0
!
After all, it's just a question of practical notational conventions (we don't use "hundred and twenty-three" or "CXXIII" or "v^^^^^v^^"). Python's own decoding builtins should be consistent with its own choice of notations.
d _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
--
--- You received this message because you are subscribed to a topic in the Google Groups "python-ideas" group. To unsubscribe from this topic, visit https://groups.google.com/d/ topic/python-ideas/RKQviWz9BYk/unsubscribe. To unsubscribe from this group and all its topics, send an email to python-ideas+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
On Feb 6, 2014, at 4:28, spir <denis.spir@gmail.com> wrote:
On 02/06/2014 11:24 AM, Ram Rachum wrote:
What do you think about letting the `int` constructor automatically understand the number type without specifying base if given a prefix, so int('0x3414fa') would immediately work without specifying a base of 16?
Do you mean int(numeral), where numeral is a *variable* string, with a python base prefix? (Else, just type in the constant 0x3414fa ;-) If yes, then I find it a good idea. When int() is used to decode variable numerals, it could/should/would decode all correct python numeral notations.
Note that int() also does not decode 'e' postfixes:
Of course it doesn't. A number with an e postfix is a float, not an int, so why should int parse it? You also can't use int to parse 123.45, or even 123.0, or a quoted string like "123", or "1+0j".
Python 3.3.2+ (default, Oct 9 2013, 14:50:09) [GCC 4.8.1] on linux Type "help", "copyright", "credits" or "license" for more information.
int(123e2) 12300 int("123e2") Traceback (most recent call last): File "<stdin>", line 1, in <module> ValueError: invalid literal for int() with base 10: '123e2'
But float() does:
float(-1.23e4) -12300.0 float("-1.23e4") -12300.0
!
After all, it's just a question of practical notational conventions (we don't use "hundred and twenty-three" or "CXXIII" or "v^^^^^v^^"). Python's own decoding builtins should be consistent with its own choice of notations.
In that case, int('-3') shouldn't work, because -3 is not a valid int literal in Python. (It's a unary expression with the '-' operator followed by the literal 3.)
On 02/06/2014 04:37 AM, Andrew Barnert wrote:
Of course it doesn't. A number with an e postfix is a float, not an int, so why should int parse it? You also can't use int to parse 123.45, or even 123.0, or a quoted string like "123", or "1+0j".
Python 3.4.0b3+ (default:7d0a4f89c6ce, Feb 5 2014, 17:04:36) [GCC 4.7.3] on linux Type "help", "copyright", "credits" or "license" for more information. --> int("123") 123 -- ~Etahn~
On 2014-02-06 15:16, Ethan Furman wrote:
On 02/06/2014 04:37 AM, Andrew Barnert wrote:
Of course it doesn't. A number with an e postfix is a float, not an int, so why should int parse it? You also can't use int to parse 123.45, or even 123.0, or a quoted string like "123", or "1+0j".
Python 3.4.0b3+ (default:7d0a4f89c6ce, Feb 5 2014, 17:04:36) [GCC 4.7.3] on linux Type "help", "copyright", "credits" or "license" for more information. --> int("123") 123
By "quoted string" he means '"123"'.
On 6 February 2014 12:28, spir <denis.spir@gmail.com> wrote:
Do you mean int(numeral), where numeral is a *variable* string, with a python base prefix? (Else, just type in the constant 0x3414fa ;-) If yes, then I find it a good idea. When int() is used to decode variable numerals, it could/should/would decode all correct python numeral notations.
Having a function like that might be useful, but I also find the current int() behaviour useful - so maybe just have a separate function. And actually, I think it's easy enough to build something like that based on ast.literal_eval, so maybe having a builtin for it isn't worth it...? Paul
On 2014-02-06 10:24, Ram Rachum wrote:
What do you think about letting the `int` constructor automatically understand the number type without specifying base if given a prefix, so int('0x3414fa') would immediately work without specifying a base of 16?
The base defaults to 10, but:
int('0x3241fca1', 0) 843185313
On 2/6/14 8:22 AM, MRAB wrote:
On 2014-02-06 10:24, Ram Rachum wrote:
What do you think about letting the `int` constructor automatically understand the number type without specifying base if given a prefix, so int('0x3414fa') would immediately work without specifying a base of 16?
The base defaults to 10, but:
int('0x3241fca1', 0) 843185313
I can't believe how many replies this thread got that overlooked that the built-in int() already does exactly what the OP wanted. Is it too much to ask that before you suggest changing the behavior of something, that you read *both* paragraphs of the documentation? http://docs.python.org/2/library/functions.html#int --Ned.
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
On 2/6/2014 5:24 AM, Ram Rachum wrote:
What do you think about letting the `int` constructor automatically understand the number type without specifying base if given a prefix, so int('0x3414fa') would immediately work without specifying a base of 16?
In addition to int(string, 0):
number = '0x3414fa' eval(number) 3413242
-- Terry Jan Reedy
On 2014-02-06 21:41, Terry Reedy wrote:
On 2/6/2014 5:24 AM, Ram Rachum wrote:
What do you think about letting the `int` constructor automatically understand the number type without specifying base if given a prefix, so int('0x3414fa') would immediately work without specifying a base of 16?
In addition to int(string, 0):
number = '0x3414fa' eval(number) 3413242
The disadvantage is that it'll evaluate (run) anything, so it's unsafe in the general case.
On 2/6/2014 5:04 PM, MRAB wrote:
On 2014-02-06 21:41, Terry Reedy wrote:
On 2/6/2014 5:24 AM, Ram Rachum wrote:
What do you think about letting the `int` constructor automatically understand the number type without specifying base if given a prefix, so int('0x3414fa') would immediately work without specifying a base of 16?
In addition to int(string, 0):
number = '0x3414fa' eval(number) 3413242
The disadvantage is that it'll evaluate (run) anything, so it's unsafe in the general case.
To evaluate any number expression, but only number expressions, but be safe against untrusted input, one should use ast.literal_eval, and then test that the result is a number (either with numbers.Number or adding 0 import ast from numbers import Number def get_number(prompt = "Input a number: "): s = input(prompt) try: x = ast.literal_eval(s) # raise ValueError on failure if not isinstance(x, Number): raise ValueError() except ValueError: raise ValueError("'{}' is not a Python number literal".format(s)) from None return x -- Terry Jan Reedy
On 7 Feb 2014 11:01, "Terry Reedy" <tjreedy@udel.edu> wrote:
On 2/6/2014 5:04 PM, MRAB wrote:
On 2014-02-06 21:41, Terry Reedy wrote:
On 2/6/2014 5:24 AM, Ram Rachum wrote:
What do you think about letting the `int` constructor automatically understand the number type without specifying base if given a prefix,
so
int('0x3414fa') would immediately work without specifying a base of 16?
In addition to int(string, 0):
number = '0x3414fa' eval(number) 3413242
The disadvantage is that it'll evaluate (run) anything, so it's unsafe in the general case.
To evaluate any number expression, but only number expressions, but be safe against untrusted input, one should use ast.literal_eval, and then test that the result is a number (either with numbers.Number or adding 0
If you want to support non-integers, yes. But in most cases where prefix interpretation is of interest, you will specifically want an integer (so base 0 is the answer), and in other cases, base 10 integer strings are also valid input for the float or Decimal constructor. Cheers, Nick.
import ast from numbers import Number
def get_number(prompt = "Input a number: "): s = input(prompt) try: x = ast.literal_eval(s) # raise ValueError on failure if not isinstance(x, Number): raise ValueError() except ValueError: raise ValueError("'{}' is not a Python number literal".format(s))
from None
return x
-- Terry Jan Reedy
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
participants (11)
-
Andrew Barnert -
Ethan Furman -
Ian Cordasco -
MRAB -
Ned Batchelder -
Nick Coghlan -
Paul Moore -
Ram Rachum -
Ram Rachum -
spir -
Terry Reedy