[Edu-sig] The fate of raw_input() in Python 3000

[John Zelle]

I agree whole-heartedly with Andre on this (except that I also want to 
preserve input, see below). I understand the rationale for eliminating 
the "redundancy" of these statements, but of course the same argument holds 
for the print statement. Why not do away with it and just use sys.stdout? 

The reason is that programs, almost by definition, do input and output. 
Indeed, one very frutiful way of viewing programs is as a mapping from input 
to outputs. Given that, any language that does not include both input and 
output in its core functionality just feels wrong to me. It's one of the 
weaknesses of languages like C++ and Java that the simplest possible programs 
(ones that do lowly text IO) require "extra" machinery beyond the standard 
built-ins. This isn't just another barrier for novices either; it's also an 
extra burden for the average script writer. Looking at my own code, this 
change "breaks" virtually everything I have written while at the same time 
adding extra bulk and decreasing clarity and intent. 

On Monday 04 September 2006 7:45 pm, Andre Roberge wrote:
> The following is something I have been pondering for quite a while now
> and am wondering what other people on this list think.
>
> According to PEP 3100
> (http://www.python.org/dev/peps/pep-3100/ )
> raw_input()  [as well as input()] is recommended for removal from the
> built-in namespace, to be replaced by sys.stdin.readline().
>
> While I don't think anyone can argue that this removal makes a major
> difference for Python as a programming language, I believe it makes a
> significant difference for using Python as a learning language, adding
> a non-trivial barrier to learning.
>
> Consider the following fake sessions at the interpreter prompt, where
> I use extra parentheses to turn print as a function (as is also
> proposed in Python 3000) - these parentheses can of course be used
> with today's Python.
>
> # First ever program
>
> >>> print("Hello world!")
>
> Hello world!
>
> # More complicated example from the first interactive session using
> today's version
>
> >>> name = raw_input("Enter your name: ")
>
> Enter your name: Andre
>
> >>> print("Hello " + name + "!")
>
> Hello Andre!
>
> # More or less the same example using the proposed changes.
>
> >>> import sys
> >>> print("Enter your name: ")
>
> Enter your name:
> >>> name = sys.stdin.readline()
>
> <-- Andre
>
> >>> print("Hello " + name + "!")
>
> Hello Andre!
>
> To explain the above *simple* program to a beginner, we'd need:
> 1. to introduce the import statement
> 2. to introduce the dot notation (something Kirby would be happy with ;-)
>
> Furthermore, the flow is not the same as with today's raw_input().
>
> I don't like it.
>
> While I totally agree with the proposed removal of input()  [anything
> using eval() in a hidden way is *bad*], my preference would be to keep
> raw_input()'s functionality, perhaps renaming it to user_input() or
> ask_user().

No! Keep input too! It's the single handiest input statement from any language 
I've ever used. Dangerous? You bet. But also very, very handy -- especially 
for simple introductory programs. By the time students are writing production 
code, they should have a very good handle on what input does behind the 
scenes. I also like the naming of input and raw_input as they stand. It 
provides a perfect vehicle for explaining what eval is all about.

>
> Thoughts?

Of course, Guido has always been right in the past :-) But this change just 
feels wrong to me. It brings a certain consistency at the cost of both 
efficiency (requiring more code) and charm. Perhaps our BDFL will yet see the 
light on this one.

--John

John M. Zelle, Ph.D.             Wartburg College
Professor of Computer Science    Waverly, IA     
john.zelle at wartburg.edu          (319) 352-8360