Input() in Python3

[harrismh777]

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

 

[Chris Angelico]

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]

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

 

[Chris Rebert]

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

 

[Westley Martínez]

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.


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]

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.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):
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):


Mel.

 

[Chris Angelico]

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]

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.
.... sys.exit(42)
.... except SystemExit as e:
.... print(e.code)
....
42

 

[Chris Angelico]

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]

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.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):
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):


Mel.

What?

 

[harrismh777]

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

 

[Mel]

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.