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

[John Zelle]

On Monday 04 September 2006 8:56 pm, Dethe Elza wrote:
> On 4-Sep-06, at 5: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().
>
> But it is trivial to add this back in:
>  >>> raw_input = sys.stdin.readline

This is simply not equivalent. readline does not take a prompt as an argument. 
You'll have to write the function.

> > 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.
>
> Removing this from built-ins isn't going to be any more confusing or
> off-putting than trying to understand the difference between input
> and raw_input in the first place.  I remember being tripped up by
> *that* when I was first learning Python.

My hunch is that your confusion came because of your experience with other 
languages. Having an input statement that evaluates just like what you type 
into the code is a _wonderful_ teaching tool. An input is just a "delayed 
expression."  value = input("Enter an expression: ") where the input is 3+4*5 
is just like the line of code value = 3+4*5. Students find that very easy to 
understand. 

> > 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.
>
> The standard prompt is great, but not the best learning environment.
> I would recommend that students use IPython instead, and since
> IPython already adds lots of convenience methods to the global
> namespace, there's nothing to stop it from pre-populating globals
> with input and raw_input.
>

Sure, there are better learning environments. But the standard prompt is _the 
sole arbiter_ of what _Python_ actually does. Whenever you want students to 
figure out a feature of the language, the interactive prompt is the way to 
go. Let's see how Python interprets that. Using some other environment with 
built-in defs is not giving you Python.

> That is:
>
> 1. It isn't necessary for global functions at the command-line prompt
> to be in builtins

But it's useful. See my message that passed yours in cyberspace.

> 2. It possible (and desirable) to have different command-line prompts
> for different purposes
sure.

> 3. It isn't necessary to clutter the builtins with every convenience
> function, even if we're used to it

Built-ins should not be cluttered with _every convenience_, but requiring an 
import to do _any_ input is silly. Input is not a convenience, it's virtually 
part of the definition of a useful program.

> Now, all that given, I do hope Python doesn't start going down the
> road that Java has taken and replace
>
>  >>> open('myfilename.txt')
>
> with
>
>  >>> open(BufferedStream(InputStream(FileStream('myfilename.txt')

This looks like a step in that direction to me. I would like to see a "Zipf 
diagram" that shows an analysis of the prevelance of various built-ins in 
extant Python code. I'm betting input has been used over the years as a core 
feature. It's part of what makes Python Python. While we're at it, isn't 
opening a file something that really happens at a system or OS level? Perhaps 
it should be something like:

>>>files.PythonFile(os.open(BufferedStream(InputStream(FileStream('myfilename.txt')))))

Why should file opening be any more of a "convenience" than asking the user 
for input, after all?

> but I don't think the loss of raw_input is quite on that scale.

It may not be on that scale, but it would certainly cause me to survey the 
language landscape again to see if there are better languages for teaching. 
I/O is a core concept in programming, period. Don't make me introduce 
extended libraries (via import) in order to teach a core concept.

--John

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