question about input() and/or raw_input()

[Roy Smith]

Pardon me for being cynical, but in the entire history of the universe,
has anybody ever used input()/raw_input() for anything other than a
homework problem?

 

[Mark Lawrence]

Pardon me for being cynical, but in the entire history of the universe,
has anybody ever used input()/raw_input() for anything other than a
homework problem?

Not me personally. I guess raw_input must have been used somewhere at
some time for something, or it would have been scrapped in Python 3, not
renamed to input.

 

[Emile van Sebille]

Pardon me for being cynical, but in the entire history of the universe,
has anybody ever used input()/raw_input() for anything other than a
homework problem?

Yes - routinely.

Emile

 

[Peter Otten]

Pardon me for being cynical, but in the entire history of the universe,
has anybody ever used input()/raw_input() for anything other than a
homework problem?

I use it for pointless throwaway tools, sometimes via the cmd module,
sometimes directly.

I like that you can add tab-completion.

 

[Terry Reedy]

Pardon me for being cynical, but in the entire history of the universe,
has anybody ever used input()/raw_input() for anything other than a
homework problem?

Homework problems (and 'toy' programs, such as hangman), whether in a
programming class or elsewhere, are one of the intended use cases of
Python. How else would you get interactive input without the complexity
of a gui?

 

[Dennis Lee Bieber]

Pardon me for being cynical, but in the entire history of the universe,
has anybody ever used input()/raw_input() for anything other than a
homework problem?

Quite often... Most of my "applications" are short things that don't
justify the effort of a GUI, but don't fit the command-line option only
mode of usage. raw_input() works quite well with providing user prompts.

 

[Chris Angelico]

Homework problems (and 'toy' programs, such as hangman), whether in a
programming class or elsewhere, are one of the intended use cases of Python.
How else would you get interactive input without the complexity of a gui?

With the network I've written plenty of programs whose sole
interaction is via sockets (telnet, HTTP, SMTP, whatever), or a
database, or somesuch.

But I've also written my share of interactive programs that use the
console. Plenty of programs don't need the fanciness of a GUI, but
need to prompt the user for stuff. If I write something for my brother
(and only him), I'm inclined to spend less effort on the UI than I
would for something of wide distribution, and console I/O is
approximately zero effort.

BTW, I'm assuming your mention of "input()/raw_input()" is covering
Py3 and Py2, respectively. I have *never* used input() in live Py2
code, and never intend to. It's way too subtle. On those really rare
occasions when you actually want to take something from the user and
immediately eval it, the extra keystrokes for eval(raw_input()) are,
IMO, a small price for the clarity.

ChrisA

 

[Rustom Mody]

Pardon me for being cynical, but in the entire history of the universe,
has anybody ever used input()/raw_input() for anything other than a
homework problem?

Similar 'cynicism' regarding print would be salutary for producing better programmers

[If youve taught programming and had to deal with code strewn with prints...]

 

[Chris Angelico]

Pardon me for being cynical, but in the entire history of the universe,
has anybody ever used input()/raw_input() for anything other than a
homework problem?

Similar 'cynicism' regarding print would be salutary for producing better programmers

[If youve taught programming and had to deal with code strewn with prints...]

Why, exactly? How ought a program to produce filterable output?

ChrisA

 

[Rustom Mody]

Pardon me for being cynical, but in the entire history of the universe,
has anybody ever used input()/raw_input() for anything other than a
homework problem?

Similar 'cynicism' regarding print would be salutary for producing better programmers
[If youve taught programming and had to deal with code strewn with prints...]

Why, exactly? How ought a program to produce filterable output?

Because these two pieces of code

look identical (to a beginner at least)

And so if they see prints used cavalierly for demo purposes, they think the
prints are also ok for production.

As a professional programmer, you would of course understand
- 'normal' code that does some processing and then some output should not
have prints in the processing
- web-serving (type of) code that has little other than heavy-duty printing
should probably use a template engine of some sort

In any case prints all over is a code-smell
exacerbated by the way that manuals/examples need to be written

 

[Chris Angelico]

Because these two pieces of code


look identical (to a beginner at least)

As do these pieces of code:

def quux(x): return str(x+1)
def quux(x): return hex(x+1)[2:]

But we don't decry hex or str because of it. Every function has its
use and purpose. If someone uses the wrong tool for the job, s/he will
have to figure that out at some point - it doesn't mean the tool is
wrong.

If you're not using the REPL, print is critical. Don't assume everyone
uses interactive mode.

ChrisA

 

[Steven D'Aprano]

Pardon me for being cynical, but in the entire history of the universe,
has anybody ever used input()/raw_input() for anything other than a
homework problem?

Yes. They are excellent for interactive command line tools.

 

[Rustom Mody]

Because these two pieces of code
look identical (to a beginner at least)

As do these pieces of code:

def quux1(x): return str(x+1)
def quux2(x): return hex(x+1)[2:]

They do?

'3.3'

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 1, in quux2
TypeError: hex() argument can't be converted to hex


If you want to give an irrelevant example at least give a correct one
the difference between str and hex is an arcane difference (Ive never used hex)
the difference between functions and procedures is absolutely basic.

And python is worse than not just academic languages like haskell in this
respect but even worse than C/Pascal etc.

In Pascal, the difference between procedure and function is
fundamental to the lang and is key to Pascal being good for academic
purposes.

In C, the difference is not so well marked but at least trivial
code-examples found in books/the net wont run straight-off without
some main-printf-etc boiler-plate.

In python lots of easy to check examples run straight off --
convenient for programmers of course but a headache for teachers who
are trying to set habits of minimal hygiene

But we don't decry hex or str because of it. Every function has its
use and purpose. If someone uses the wrong tool for the job, s/he will
have to figure that out at some point - it doesn't mean the tool is
wrong.

If you're not using the REPL, print is critical. Don't assume everyone
uses interactive mode.

"Everyone uses interactive mode" is of course an unreasonable assumption
"Everyone needs to learn (something or other at some time or other)" is not

And print (especially in python) screws up the learning-curve

tl;dr
You are wearing 'professional programmer' hat
I am wearing 'teacher' hat
Not sure what hat Roy or Steven are wearing

 

[Chris Angelico]

If you want to give an irrelevant example at least give a correct one
the difference between str and hex is an arcane difference (Ive never used hex)
the difference between functions and procedures is absolutely basic.

They don't give the same result for every possible input, any more
than your two do:
2.234567890123456

(Tested on 2.7.3 on Linux. YMMV.)

There's no difference in Python between functions and procedures. It's
all functions, and some of them implicitly return None. If there were
a difference, what would this be?

def none_if(value, predicate):
if not predicate(value): return value

Personally, I'm quite happy with Python and the print function. (Or
statement, if you prefer. Same difference.) The most fundamental
aspects of any program are input, output, and preferably some
computation in between; and the most fundamental forms of input are
the command line / console and the program's source, and the most
basic output is the console. So the most basic and obvious program
needs:

1) Access to the command-line arguments
2) The ability to read from the console
3) Some means of writing to the console.

Not every program will need all that, but they'd be the most obvious
and simplest methods of communication - especially since they're the
three that are easiest to automate. How do you run a GUI program
through automated testing? With difficulty. How do you run a stdio
program through automated testing? Pipe it some input and compare its
output to the standard. And that means people should be accustomed to
using print, and sys.argv, and (raw_)input.

Fortunately Python doesn't have ob_start() / ob_get_clean() to tempt
people to use print when they should use return. So there's no
problem.

ChrisA

 

[Ethan Furman]

As do these pieces of code:

--> def quux1(x): return str(x+1)
--> def quux2(x): return hex(x+1)[2:]

They do?

--> quux1(2.3)
'3.3'

--> quux2(2.3)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 1, in quux2
TypeError: hex() argument can't be converted to hex

(Will be) fixed in 3.5 [1]

 

[Grant Edwards]

Homework problems (and 'toy' programs, such as hangman), whether in a
programming class or elsewhere, are one of the intended use cases of
Python. How else would you get interactive input without the complexity
of a gui?

sys.stdin.readline()

 

[Chris Angelico]

--> quux1(2.3)
'3.3'

(Will be) fixed in 3.5 [1]
[1] Which is to say, both will raise an exception.

Why would that raise?

ChrisA

 

[Dennis Lee Bieber]

sys.stdin.readline()

At which point a simple:

nm = raw_input("Enter your name: ")
print "Hello, ", nm

turns into (to duplicate the behavior WRT line endings, and to minimize the
new features the student is exposed to)

import sys

sys.stdout.write("Enter your name: ")
nm = sys.stdin.readline()
nm.strip()
sys.stdout.write("Hello, ")
sys.stdout.write(nm)
sys.stdout.write("\n")
sys.stdout.flush()

Yes, a non-beginner would have been exposed to formatting operations
and been able to condense the three .write() calls into one... But the
assignment has gone from "learn how to do simple input and output" into
"learn about importable modules, learn how to handle line endings, and
maybe figure out simple I/O in all of that"

If that was the only route I'd rapidly end up creating a utility module
with, to start with, a simple <?>

import sys

def input(prompt=None):
if prompt:
sys.stdout.write(prompt)
return sys.stdin.readline().strip()


I rarely find a need to work at the sys.std*** level. Anything needing
that level of control is probably using a data file specified on the
command line and not interactive console...

 

[Grant Edwards]

At which point a simple:

nm = raw_input("Enter your name: ")
print "Hello, ", nm

turns into (to duplicate the behavior WRT line endings, and to minimize the
new features the student is exposed to)

import sys

sys.stdout.write("Enter your name: ")
nm = sys.stdin.readline()
nm.strip()
sys.stdout.write("Hello, ")
sys.stdout.write(nm)
sys.stdout.write("\n")
sys.stdout.flush()

The question was how to get input without using a GUI. I presented an
answer. You then conflated "whether or not to use input" with
"whether or not to use print" and proceeded to construct and knock
down a very nice straw man. Kudos.

import sys
print "Enter your name: ",
nm = sys.stdin.readline().strip()
print "Hello, ", nm

Yes, a non-beginner would have been exposed to formatting operations
and been able to condense the three .write() calls into one...

1) I don't get why you jumped on the whole print vs. string formatting
thing. We're not talking about print vs write. We're talking
about whether or not people use input and raw_input. I've been
writing Python programs for 15 years, and I've never used either
input or raw_input.

2) I didn't claim that sys.stdin.readline() was as simple as using
input. I didn't claim it was preferable. I merely presented it as
a refutation to the argument that if you don't use input/raw_input
then you have to use a GUI toolkit.

 

[Ethan Furman]

--> def quux1(x): return str(x+1)
--> quux1(2.3)
'3.3'

(Will be) fixed in 3.5 [1]
[1] Which is to say, both will raise an exception.

Why would that raise?

Sorry, should have read that closer. It will not raise.

The difference I was thinking of is:

"%h" % 3.14 # this works

vs.

hex(3.14) # this raises

In 3.5 both will raise.

Apologies for the noise.