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

[dblank at brynmawr.edu]

I also agree with y'all, but there is a subtlety that I don't like with
the current names and which might explain the confusion: raw_input() does
less than input(), but looks and sounds like it does more. I might like
something similar to:

>>> name = ask("What is your name? ")
What is your name? John
>>> seconds = askexp("What is your age, in days? ")
What is your age, in days? 43 * 365

or read(), and readeval(); or prompt(), and eval(prompt()).

But, I really hope that they keep an easy-to-use version.

-Doug

> 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
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> http://mail.python.org/mailman/listinfo/edu-sig
>