On Feb 6, 2014, at 4:44, Ram Rachum <ram.rachum@gmail.com> wrote:
Ah, you're talking about non-programmers. I can't imagine though a non-programmer seriously complaining that "0x0" is a number while "0z" isn't.
Can you please read the whole sentence before replying to it? I specifically said "Would a newbie--or a non-programmer using a program--understand..." And you can't imagine a non-programmer complaining that "0123" is either not a number, or the number 83?
On Thu, Feb 6, 2014 at 2:41 PM, Andrew Barnert <abarnert@yahoo.com> wrote:
On Feb 6, 2014, at 4:35, Ram Rachum <ram.rachum@gmail.com> wrote:
On Thu, Feb 6, 2014 at 2:31 PM, Andrew Barnert <abarnert@yahoo.com> wrote:
On Feb 6, 2014, at 4:19, Ram Rachum <ram.rachum@gmail.com> wrote:
I don't understand... The newbie will pass '0x13412' to the int constructor by mistake and be surprised when it's parsed as hex? Doesn't make sense does it?
Would a newbie--or a non-programmer using a program--understand why, say, "0X0" counts as a valid number but "0Z" doesn't?
Since they're likely to get the same confusion while feeding literals to the Python shell, I think this is acceptable.
You think it's acceptable that a non-programmer should have to understand the python shell to use any program written in Python?
On Thu, Feb 6, 2014 at 2:47 PM, Andrew Barnert <abarnert@yahoo.com> wrote:
On Feb 6, 2014, at 4:44, Ram Rachum <ram.rachum@gmail.com> wrote:
Ah, you're talking about non-programmers. I can't imagine though a non-programmer seriously complaining that "0x0" is a number while "0z" isn't.
Can you please read the whole sentence before replying to it? I specifically said "Would a newbie--or a non-programmer using a program--understand..."
And you can't imagine a non-programmer complaining that "0123" is either not a number, or the number 83?
You're right. I suggest int would just throw away the leading zeroes. In Python 3.x there's no meaning to them without 0o or 0x or 0b anyway, right?
On Thu, Feb 6, 2014 at 2:41 PM, Andrew Barnert <abarnert@yahoo.com> wrote:
On Feb 6, 2014, at 4:35, Ram Rachum <ram.rachum@gmail.com> wrote:
On Thu, Feb 6, 2014 at 2:31 PM, Andrew Barnert <abarnert@yahoo.com>wrote:
On Feb 6, 2014, at 4:19, Ram Rachum <ram.rachum@gmail.com> wrote:
I don't understand... The newbie will pass '0x13412' to the int constructor by mistake and be surprised when it's parsed as hex? Doesn't make sense does it?
Would a newbie--or a non-programmer using a program--understand why, say, "0X0" counts as a valid number but "0Z" doesn't?
Since they're likely to get the same confusion while feeding literals to the Python shell, I think this is acceptable.
You think it's acceptable that a non-programmer should have to understand the python shell to use any program written in Python?
On 6 February 2014 12:51, Ram Rachum <ram.rachum@gmail.com> wrote:
And you can't imagine a non-programmer complaining that "0123" is either not a number, or the number 83?
You're right. I suggest int would just throw away the leading zeroes. In Python 3.x there's no meaning to them without 0o or 0x or 0b anyway, right?
Once you get to this point, you're writing your own spec for what input you want to allow, and you're probably better off writing your own code that meets that spec. Sanitising the string how you want then calling ast.literal_eval is easy enough. -1 on changing the behaviour of int. -0.5 on adding a new builtin (I see no need for it, but if others do, it won't cause me any issues if it exists...). +1 on adding documentation examples showing how to use ast.literal_eval to write your own specialised evaluators. Paul.
On Feb 6, 2014, at 4:51, Ram Rachum <ram.rachum@gmail.com> wrote:
On Thu, Feb 6, 2014 at 2:47 PM, Andrew Barnert <abarnert@yahoo.com> wrote:
On Feb 6, 2014, at 4:44, Ram Rachum <ram.rachum@gmail.com> wrote:
Ah, you're talking about non-programmers. I can't imagine though a non-programmer seriously complaining that "0x0" is a number while "0z" isn't.
Can you please read the whole sentence before replying to it? I specifically said "Would a newbie--or a non-programmer using a program--understand..."
And you can't imagine a non-programmer complaining that "0123" is either not a number, or the number 83?
You're right. I suggest int would just throw away the leading zeroes. In Python 3.x there's no meaning to them without 0o or 0x or 0b anyway, right?
As a literal in Python source, there are good reasons for it to be an error--because in Python 2.x, in many other languages, in various shell command invocations that you might want to convert from bash scripts to Python, etc., it means octal. Someone who types "0123" into Python source code could just as easily mean 83 as 123, and that's why it's an error. As input from an end user, on the other hand, "0123" clearly means 123, not 83. And that's a perfect example of why int(s) should not always do the same thing as the interactive interpreter. When you _want_ the same behavior as the interpreter, it's trivial to get it. When you want to treat end user data--or data from some file format or protocol, or whatever--as a string representation of an integer, rather than as a string representation of a Python integer literal--why shouldn't that be spelled int(s)?
On Thu, Feb 6, 2014 at 2:41 PM, Andrew Barnert <abarnert@yahoo.com> wrote:
On Feb 6, 2014, at 4:35, Ram Rachum <ram.rachum@gmail.com> wrote:
On Thu, Feb 6, 2014 at 2:31 PM, Andrew Barnert <abarnert@yahoo.com> wrote:
On Feb 6, 2014, at 4:19, Ram Rachum <ram.rachum@gmail.com> wrote:
> I don't understand... The newbie will pass '0x13412' to the int constructor by mistake and be surprised when it's parsed as hex? Doesn't make sense does it?
Would a newbie--or a non-programmer using a program--understand why, say, "0X0" counts as a valid number but "0Z" doesn't?
Since they're likely to get the same confusion while feeding literals to the Python shell, I think this is acceptable.
You think it's acceptable that a non-programmer should have to understand the python shell to use any program written in Python?
participants (3)
-
Andrew Barnert -
Paul Moore -
Ram Rachum