Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #64244 > unrolled thread

question about input() and/or raw_input()

Back to article view | Back to comp.lang.python

Contents

  question about input() and/or raw_input() Roy Smith <roy@panix.com> - 2014-01-18 13:30 -0500
    Re: question about input() and/or raw_input() Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-01-18 18:41 +0000
    Re: question about input() and/or raw_input() Emile van Sebille <emile@fenx.com> - 2014-01-18 10:49 -0800
    Re: question about input() and/or raw_input() Peter Otten <__peter__@web.de> - 2014-01-18 20:05 +0100
    Re: question about input() and/or raw_input() Terry Reedy <tjreedy@udel.edu> - 2014-01-18 16:33 -0500
      Re: question about input() and/or raw_input() Grant Edwards <invalid@invalid.invalid> - 2014-01-19 16:14 +0000
        Re: question about input() and/or raw_input() Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-01-19 12:12 -0500
          Re: question about input() and/or raw_input() Grant Edwards <invalid@invalid.invalid> - 2014-01-19 17:42 +0000
            Re: question about input() and/or raw_input() Chris Angelico <rosuav@gmail.com> - 2014-01-20 04:59 +1100
    Re: question about input() and/or raw_input() Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-01-18 21:17 -0500
    Re: question about input() and/or raw_input() Chris Angelico <rosuav@gmail.com> - 2014-01-19 13:46 +1100
    Re: question about input() and/or raw_input() Rustom Mody <rustompmody@gmail.com> - 2014-01-18 20:15 -0800
      Re: question about input() and/or raw_input() Chris Angelico <rosuav@gmail.com> - 2014-01-19 15:21 +1100
        Re: question about input() and/or raw_input() Rustom Mody <rustompmody@gmail.com> - 2014-01-18 20:43 -0800
          Re: question about input() and/or raw_input() Chris Angelico <rosuav@gmail.com> - 2014-01-19 15:59 +1100
            Re: question about input() and/or raw_input() Rustom Mody <rustompmody@gmail.com> - 2014-01-19 00:26 -0800
              Re: question about input() and/or raw_input() Chris Angelico <rosuav@gmail.com> - 2014-01-19 21:39 +1100
              Re: question about input() and/or raw_input() Ethan Furman <ethan@stoneleaf.us> - 2014-01-19 08:14 -0800
              Re: question about input() and/or raw_input() Chris Angelico <rosuav@gmail.com> - 2014-01-20 03:38 +1100
              Re: question about input() and/or raw_input() Ethan Furman <ethan@stoneleaf.us> - 2014-01-19 09:50 -0800
              Re: question about input() and/or raw_input() Chris Angelico <rosuav@gmail.com> - 2014-01-20 05:41 +1100
              Re: question about input() and/or raw_input() Ethan Furman <ethan@stoneleaf.us> - 2014-01-19 11:16 -0800
    Re: question about input() and/or raw_input() Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-01-19 06:24 +0000
    Re: question about input() and/or raw_input() Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-01-19 18:07 +0000
      Re: question about input() and/or raw_input() Grant Edwards <invalid@invalid.invalid> - 2014-01-19 18:15 +0000
        Re: question about input() and/or raw_input() Roy Smith <roy@panix.com> - 2014-01-19 13:37 -0500
          Re: question about input() and/or raw_input() Chris Angelico <rosuav@gmail.com> - 2014-01-20 05:43 +1100
          Re: question about input() and/or raw_input() Grant Edwards <invalid@invalid.invalid> - 2014-01-19 19:11 +0000
          Re: question about input() and/or raw_input() Gene Heskett <gheskett@wdtv.com> - 2014-01-19 15:09 -0500
        Re: question about input() and/or raw_input() Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-01-19 19:17 +0000
        Re: question about input() and/or raw_input() Larry Martell <larry.martell@gmail.com> - 2014-01-19 12:24 -0700
        Re: question about input() and/or raw_input() Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-01-19 19:29 +0000
    Re: question about input() and/or raw_input() Gene Heskett <gheskett@wdtv.com> - 2014-01-19 15:12 -0500
    Re: question about input() and/or raw_input() Larry Martell <larry.martell@gmail.com> - 2014-01-19 13:22 -0700

Page 1 of 2  [1] 2  Next page →

#64244 — question about input() and/or raw_input()

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?

[toc] | [next] | [standalone]

#64245

On 18/01/2014 18:30, Roy Smith wrote:
> 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.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#64247

On 01/18/2014 10:30 AM, Roy Smith wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#64249

Roy Smith wrote:

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

[toc] | [prev] | [next] | [standalone]

#64259

On 1/18/2014 1:30 PM, Roy Smith wrote:
> 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?

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#64296

On 2014-01-18, Terry Reedy <tjreedy@udel.edu> wrote:
> On 1/18/2014 1:30 PM, Roy Smith wrote:
>> 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?

sys.stdin.readline()

[toc] | [prev] | [next] | [standalone]

#64300

On Sun, 19 Jan 2014 16:14:48 +0000 (UTC), Grant Edwards
<invalid@invalid.invalid> declaimed the following:

>On 2014-01-18, Terry Reedy <tjreedy@udel.edu> wrote:
>> On 1/18/2014 1:30 PM, Roy Smith wrote:
>>> 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?
>
>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...
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#64301

On 2014-01-19, Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:
> On Sun, 19 Jan 2014 16:14:48 +0000 (UTC), Grant Edwards
><invalid@invalid.invalid> declaimed the following:
>
>>On 2014-01-18, Terry Reedy <tjreedy@udel.edu> wrote:
>>> On 1/18/2014 1:30 PM, Roy Smith wrote:
>>>> 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?
>>
>>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()

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.

-- 
Grant

[toc] | [prev] | [next] | [standalone]

#64302

On Mon, Jan 20, 2014 at 4:42 AM, Grant Edwards <invalid@invalid.invalid> wrote:
> 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.

I'd draw a subtle distinction here, btw. With sys.stdin.readline(),
you're asking to read a line from standard input, but with
(raw_)input(), you're asking to read one line from the console. If
it's been redirected, that's going to be equivalent (modulo newline
handling), but if not, it would make sense for (raw_)input() to call
on GNU Readline, where sys.stdin.readline() shouldn't. Calling a
method on a file-like object representing stdin feels lower level than
"ask the user for input with this prompt" (which might well do more
than that, too - eg it might flush sys.stdout).

ChrisA

[toc] | [prev] | [next] | [standalone]

#64274

On Sat, 18 Jan 2014 13:30:20 -0500, Roy Smith <roy@panix.com> declaimed the
following:

>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.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#64275

On Sun, Jan 19, 2014 at 8:33 AM, Terry Reedy <tjreedy@udel.edu> wrote:
> On 1/18/2014 1:30 PM, Roy Smith wrote:
>>
>> 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?

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

[toc] | [prev] | [next] | [standalone]

#64277

On Sunday, January 19, 2014 12:00:20 AM UTC+5:30, Roy Smith wrote:
> 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...]

[toc] | [prev] | [next] | [standalone]

#64278

On Sun, Jan 19, 2014 at 3:15 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> On Sunday, January 19, 2014 12:00:20 AM UTC+5:30, Roy Smith wrote:
>> 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

[toc] | [prev] | [next] | [standalone]

#64279

On Sunday, January 19, 2014 9:51:36 AM UTC+5:30, Chris Angelico wrote:
> On Sun, Jan 19, 2014 at 3:15 PM, Rustom Mody  wrote:
> > On Sunday, January 19, 2014 12:00:20 AM UTC+5:30, Roy Smith wrote:
> >> 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

>>> def foo(x): print x+1

>>> def bar(x): return x+1

look identical (to a beginner at least)

>>> foo(3)
4
>>> bar(3)
4
>>> 

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

[toc] | [prev] | [next] | [standalone]

#64280

On Sun, Jan 19, 2014 at 3:43 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> Because these two pieces of code
>
>>>> def foo(x): print x+1
>
>>>> def bar(x): return x+1
>
> look identical (to a beginner at least)
>
>>>> foo(3)
> 4
>>>> bar(3)
> 4
>>>>

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

[toc] | [prev] | [next] | [standalone]

#64287

On Sunday, January 19, 2014 10:29:58 AM UTC+5:30, Chris Angelico wrote:
> On Sun, Jan 19, 2014 at 3:43 PM, Rustom Mody wrote:
> > Because these two pieces of code
> >>>> def foo(x): print x+1
> >>>> def bar(x): return x+1
> > look identical (to a beginner at least)
> >>>> foo(3)
> > 4
> >>>> bar(3)
> > 4

> 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


If you want to give an irrelevant example at least give a correct one :D
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 

[toc] | [prev] | [next] | [standalone]

#64291

On Sun, Jan 19, 2014 at 7:26 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> If you want to give an irrelevant example at least give a correct one :D
> 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:

>>> foo(1.234567890123456)
2.23456789012
>>> bar(1.234567890123456)
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

[toc] | [prev] | [next] | [standalone]

#64298

On 01/19/2014 12:26 AM, Rustom Mody wrote:
> On Sunday, January 19, 2014 10:29:58 AM UTC+5:30, Chris Angelico wrote:
>> On Sun, Jan 19, 2014 at 3:43 PM, Rustom Mody wrote:
>>>
>> 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]  :)

--
~Ethan~

[1] Which is to say, both will raise an exception.

[toc] | [prev] | [next] | [standalone]

#64299

On Mon, Jan 20, 2014 at 3:14 AM, Ethan Furman <ethan@stoneleaf.us> wrote:
>>> --> 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?

ChrisA

[toc] | [prev] | [next] | [standalone]

#64305

On 01/19/2014 08:38 AM, Chris Angelico wrote:
> On Mon, Jan 20, 2014 at 3:14 AM, Ethan Furman <ethan@stoneleaf.us> wrote:
>>>> --> 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.

--
~Ethan~

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.python

csiph-web