FAQ
My interactive scripts are giving errors on the input(). I discovered
another fairly significant change in Python3, as discussed in PEP 3111.

I was a little flabbergasted to discover that input() was proposed to be
removed 'totally' from 3000. Of course I agree with PEP 3111 and am
thankful that input() is still a built-in. doh.

The problem is that the behavior was significantly changed, again,
causing existing code to break un-necessarily. So, input() used to be
equivalent to:

eval(raw_input("prompt>")) --> value


now we get this for input():


raw_input("prompt>") --> string


I'm not whining or anything, just wondering why? Could someone enlighten
me please?

Anyway, it looks like the best fix for 2.x --> 3.x code changes:

change: a = input("enter a number > ")

to: a = eval(input("enter a number > "))


Again, this is just another example where leaving the advertised
interface alone would have made more sense... unless of course, I'm
missing something important here.

kind regards,
m harris

Search Discussions

  • Chris Angelico at Apr 22, 2011 at 6:49 am

    On Fri, Apr 22, 2011 at 4:22 PM, harrismh777 wrote:
    now we get this for input():

    ? raw_input("prompt>") --> string
    I would have to say that the 2.x behaviour of input() is a mistake
    that's being corrected in 3.x. With a simple name like input(), it
    should do something simple and straightforward - not eval() the
    expression.
    to: ? ? ? ?a = eval(input("enter a number > "))
    Uhhhh.... NO. NO NO NO. What if someone enters "os.exit()" as their
    number? You shouldn't eval() unchecked user input!

    Chris Angelico
  • Chris Angelico at Apr 22, 2011 at 6:50 am

    On Fri, Apr 22, 2011 at 4:49 PM, Chris Angelico wrote:
    Uhhhh.... NO. NO NO NO. What if someone enters "os.exit()" as their
    number? You shouldn't eval() unchecked user input!
    Whoops, I meant sys.exit() - but you probably knew that already.

    ChrisA
  • Westley Martínez at Apr 22, 2011 at 1:52 pm

    On Fri, Apr 22, 2011 at 04:49:19PM +1000, Chris Angelico wrote:
    On Fri, Apr 22, 2011 at 4:22 PM, harrismh777 wrote:
    now we get this for input():

    ? raw_input("prompt>") --> string
    I would have to say that the 2.x behaviour of input() is a mistake
    that's being corrected in 3.x. With a simple name like input(), it
    should do something simple and straightforward - not eval() the
    expression.
    to: ? ? ? ?a = eval(input("enter a number > "))
    Uhhhh.... NO. NO NO NO. What if someone enters "os.exit()" as their
    number? You shouldn't eval() unchecked user input!

    Chris Angelico
    Right, there's no way to check you're getting a number, however using:

    a = int(input('enter a number > ')) # use float() for floats

    will raise an exception if it can't convert the string.
  • Mel at Apr 22, 2011 at 2:08 pm

    Westley Mart?nez wrote:
    On Fri, Apr 22, 2011 at 04:49:19PM +1000, Chris Angelico wrote:

    Uhhhh.... NO. NO NO NO. What if someone enters "os.exit()" as their
    number? You shouldn't eval() unchecked user input!

    Chris Angelico
    Right, there's no way to check you're getting a number, however using:

    a = int(input('enter a number > ')) # use float() for floats

    will raise an exception if it can't convert the string.
    But sys.exit() doesn't return a string. My fave is

    Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56)
    [GCC 4.4.3] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    import sys
    a = int (input ('enter a number >'))
    enter a number >sys.setrecursionlimit(1)
    Exception RuntimeError: 'maximum recursion depth exceeded while calling a
    Python object' in <type 'exceptions.RuntimeError'> ignored
    Exception RuntimeError: 'maximum recursion depth exceeded while calling a
    Python object' in <type 'exceptions.RuntimeError'> ignored
    Error in sys.excepthook:
    RuntimeError: maximum recursion depth exceeded

    Original exception was:
    Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    RuntimeError: maximum recursion depth exceeded while calling a Python object
    int (0)
    Exception RuntimeError: 'maximum recursion depth exceeded while calling a
    Python object' in <type 'exceptions.RuntimeError'> ignored
    Exception RuntimeError: 'maximum recursion depth exceeded while calling a
    Python object' in <type 'exceptions.RuntimeError'> ignored
    Error in sys.excepthook:
    RuntimeError: maximum recursion depth exceeded

    Original exception was:
    Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    RuntimeError: maximum recursion depth exceeded while calling a Python object
    >>>


    Mel.
  • Benjamin Kaplan at Apr 22, 2011 at 4:01 pm

    On Apr 22, 2011 10:12 AM, "Mel" wrote:
    Westley Mart?nez wrote:
    On Fri, Apr 22, 2011 at 04:49:19PM +1000, Chris Angelico wrote:

    Uhhhh.... NO. NO NO NO. What if someone enters "os.exit()" as their
    number? You shouldn't eval() unchecked user input!

    Chris Angelico
    Right, there's no way to check you're getting a number, however using:

    a = int(input('enter a number > ')) # use float() for floats

    will raise an exception if it can't convert the string.
    But sys.exit() doesn't return a string. My fave is

    Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56)
    [GCC 4.4.3] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    import sys
    a = int (input ('enter a number >'))
    enter a number >sys.setrecursionlimit(1)
    Exception RuntimeError: 'maximum recursion depth exceeded while calling a
    Python object' in <type 'exceptions.RuntimeError'> ignored
    Exception RuntimeError: 'maximum recursion depth exceeded while calling a
    Python object' in <type 'exceptions.RuntimeError'> ignored
    Error in sys.excepthook:
    RuntimeError: maximum recursion depth exceeded

    Original exception was:
    Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    RuntimeError: maximum recursion depth exceeded while calling a Python
    object
    int (0)
    Exception RuntimeError: 'maximum recursion depth exceeded while calling a
    Python object' in <type 'exceptions.RuntimeError'> ignored
    Exception RuntimeError: 'maximum recursion depth exceeded while calling a
    Python object' in <type 'exceptions.RuntimeError'> ignored
    Error in sys.excepthook:
    RuntimeError: maximum recursion depth exceeded

    Original exception was:
    Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    RuntimeError: maximum recursion depth exceeded while calling a Python object

    Mel.
    We're talking about python 3, not python 2. If you're using python 2, the
    equivalent code would be int(raw_input()) and that isn't vulnerable to this
    sort of thing.
  • Chris Angelico at Apr 22, 2011 at 8:25 pm

    On Sat, Apr 23, 2011 at 12:08 AM, Mel wrote:
    But sys.exit() doesn't return a string. ?My fave is
    It doesn't return _at all_. Boom, process terminated.

    Chris Angelico
  • Steven D'Aprano at Apr 22, 2011 at 11:55 pm

    On Sat, 23 Apr 2011 06:25:51 +1000, Chris Angelico wrote:
    On Sat, Apr 23, 2011 at 12:08 AM, Mel wrote:
    But sys.exit() doesn't return a string. ?My fave is
    It doesn't return _at all_. Boom, process terminated.

    Technically it raises an exception, which can then be caught by the usual
    exception-handling mechanism. So it's not quite Boom.
    try:
    ... sys.exit(42)
    ... except SystemExit as e:
    ... print(e.code)
    ...
    42
    >>>


    --
    Steven
  • Chris Angelico at Apr 23, 2011 at 12:07 am

    On Sat, Apr 23, 2011 at 9:55 AM, Steven D'Aprano wrote:
    On Sat, 23 Apr 2011 06:25:51 +1000, Chris Angelico wrote:
    On Sat, Apr 23, 2011 at 12:08 AM, Mel wrote:
    But sys.exit() doesn't return a string. ?My fave is
    It doesn't return _at all_. Boom, process terminated.

    Technically it raises an exception, which can then be caught by the usual
    exception-handling mechanism. So it's not quite Boom.
    Sure, but it still doesn't return anything. In any case, it's not
    something you want to eval casually in the middle of asking the user
    for an integer.

    Chris Angelico
  • Westley Martínez at Apr 23, 2011 at 7:33 pm

    On Fri, Apr 22, 2011 at 10:08:20AM -0400, Mel wrote:
    Westley Mart?nez wrote:
    On Fri, Apr 22, 2011 at 04:49:19PM +1000, Chris Angelico wrote:

    Uhhhh.... NO. NO NO NO. What if someone enters "os.exit()" as their
    number? You shouldn't eval() unchecked user input!

    Chris Angelico
    Right, there's no way to check you're getting a number, however using:

    a = int(input('enter a number > ')) # use float() for floats

    will raise an exception if it can't convert the string.
    But sys.exit() doesn't return a string. My fave is

    Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56)
    [GCC 4.4.3] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    import sys
    a = int (input ('enter a number >'))
    enter a number >sys.setrecursionlimit(1)
    Exception RuntimeError: 'maximum recursion depth exceeded while calling a
    Python object' in <type 'exceptions.RuntimeError'> ignored
    Exception RuntimeError: 'maximum recursion depth exceeded while calling a
    Python object' in <type 'exceptions.RuntimeError'> ignored
    Error in sys.excepthook:
    RuntimeError: maximum recursion depth exceeded

    Original exception was:
    Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    RuntimeError: maximum recursion depth exceeded while calling a Python object
    int (0)
    Exception RuntimeError: 'maximum recursion depth exceeded while calling a
    Python object' in <type 'exceptions.RuntimeError'> ignored
    Exception RuntimeError: 'maximum recursion depth exceeded while calling a
    Python object' in <type 'exceptions.RuntimeError'> ignored
    Error in sys.excepthook:
    RuntimeError: maximum recursion depth exceeded

    Original exception was:
    Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    RuntimeError: maximum recursion depth exceeded while calling a Python object

    Mel.
    What?
  • Mel at Apr 25, 2011 at 4:50 pm

    Westley Mart?nez wrote:

    On Fri, Apr 22, 2011 at 10:08:20AM -0400, Mel wrote:
    [ ... ]
    But sys.exit() doesn't return a string. My fave is

    Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56)
    [GCC 4.4.3] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    import sys
    a = int (input ('enter a number >'))
    enter a number >sys.setrecursionlimit(1)
    Exception RuntimeError: 'maximum recursion depth exceeded while calling a
    Python object' in <type 'exceptions.RuntimeError'> ignored
    [ ... ]
    What?
    I guess sys.setrecursionlimit was meant to be called with a large number.
    Calling it with a small one roadblocks the interpreter. Luckily, there can
    be just enough room to call setrecursionlimit again with something
    reasonable to get it all back. Not enough room for `eval
    ("sys.setrecursionlimit (2000)`, though.

    Mel.
  • Jayme Proni Filho at Apr 25, 2011 at 10:08 pm
    Hey!

    Try to use like this: http://sprunge.us/RcYb

    change values for understanding code.


    Good ideas guys!
    ---------------------------------------------------------------------------------------
    Jayme Proni Filho
    Skype: jaymeproni
    Twitter: @jaymeproni
    Phone: +55 - 17 - 3631 - 6576
    Mobile: +55 - 17 - 9605 - 3560
    e-Mail: jaymeproni at yahoo dot com dot br
    ---------------------------------------------------------------------------------------
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://mail.python.org/pipermail/python-list/attachments/20110425/baa02990/attachment.html>
  • Chris Rebert at Apr 22, 2011 at 7:46 am

    On Thu, Apr 21, 2011 at 11:22 PM, harrismh777 wrote:
    My interactive scripts are giving errors on the input(). I discovered
    another fairly significant change in Python3, as discussed in PEP 3111.

    I was a little flabbergasted to discover that input() was proposed to be
    removed 'totally' from 3000. Of course I agree with PEP 3111 and am thankful
    that input() is still a built-in. ?doh.
    Well, it pretty much *was* totally removed; it was prone to misuse and
    had very few legitimate uses. It's just that raw_input() also got
    renamed simultaneously.
    What were you using it for? There are often much better alternatives.
    The problem is that the behavior was significantly changed, again, causing
    existing code to break un-necessarily.
    Python 3 has many "unnecessary" backwards-incompatible changes; the
    Python devs have made this abundantly clear and one should be aware of
    this before going into Python 3. And again, I don't think a "behavior
    change" is the best way to conceptualize this, although from a user
    perspective, there indeed isn't much difference between a behavior
    change and a simultaneous removal and renaming.
    So, input() used to be equivalent to:

    ? eval(raw_input("prompt>")) --> value


    now we get this for input():


    ? raw_input("prompt>") --> string


    I'm not whining or anything, just wondering why? Could someone enlighten me
    please?

    Anyway, it looks like the best fix for 2.x --> 3.x ?code changes:

    change: ? ?a = input("enter a number > ")

    to: ? ? ? ?a = eval(input("enter a number > "))
    Did you run your scripts through the 2to3 converter tool? This is one
    of the many changes it can apply automatically.
    Again, this is just another example where leaving the advertised interface
    alone would have made more sense... unless of course, I'm missing something
    important here.
    input() was rarely used correctly and is quite trivially replaced.
    raw_input() was used much more frequently, but was a bit awkwardly
    named. Python 3 made use of its backwards-incompatible status to
    rectify both of these problems at once. Writing correct code will be
    now easier for newbies.

    If you're porting stuff to Python 3, using 2to3 and reading the
    summary of changes from 2.x are absolute necessities.

    Cheers,
    Chris
  • Harrismh777 at Apr 24, 2011 at 1:03 am

    Chris Rebert wrote:
    Well, it pretty much*was* totally removed; it was prone to misuse and
    had very few legitimate uses. It's just that raw_input() also got
    renamed simultaneously.
    What were you using it for? There are often much better alternatives.
    For the purpose pretty much described in PEP 3111... education.

    Teaching new programmers input, control, arithmetic, logic, and output
    works best with simple built-ins. IMHO

    I want to teach young folks how to get stuff into their simple programs,
    crank on them a bit, and spit out the results... without having to teach
    them imports, libraries, &etc.

    Keep in mind that some of this stuff is very simple (say trivial) and is
    being used to provide a way to get the data 'they are expecting' into
    the program easily, with a prompt.

    This was the great concept in BASIC, and REXX, and others. The C
    language broke with this concept by declaring that the language does not
    provide I/O ... only in the standard library, as functions!

    The beauty of Python (as I've noted before) is that it can be used in an
    uber-sophisticated way... AND it can also be taught to children! Having
    thought a little more about that, I suppose that I agree that input()
    should return a raw string. After all, the students aren't really
    entering "numbers" are they?? They are entering strings of characters
    that need to be converted into numbers... easily explained... I was just
    surprised to find that issue so hotly debated... again, why remove
    something that works.

    The wisdom was to use a system call instead, right?



    kind regards,

    m harris

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppython-list @
categoriespython
postedApr 22, '11 at 6:22a
activeApr 25, '11 at 10:08p
posts14
users8
websitepython.org

People

Translate

site design / logo © 2022 Grokbase