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

[John Zelle]

First up, I support the "petition"/ suggestion whatever you want to call it. 

I'm somewhat disappointed that our discussion here seems to have gotten 
derailed by Arthur's comments that it's all about ease of teaching. I think I 
put forward a number or solid arguments about IO being core to programming 
and the expressiveness of input/raw_input that no one has bothered to 
address. Whether you want to teach import day 1 is only one small point in 
the discussion as far as I'm concerned, and that seems to be the only point 
that is picked up in certain circles.

Anyway, I also strongly support keeping the input statement, and I have to 
respectfully disagree with the comments below.

On Thursday 07 September 2006 8:49 pm, Andre Roberge wrote:
> On 9/7/06, dblank at brynmawr.edu <dblank at brynmawr.edu> wrote:
> > [Does this capture the essense of the discussion? I know some said that
> > they don't use them, and this would not stop them from not using them :)
> > -Doug]
>
> Since I raised the issue in the first place, I'll just mention again
> one additional point I raised which may have been overlooked.  It is
> generally recognized that input() == eval(raw_input()) is "not safe"
> and therefore not a good example to give to beginners.  Furthermore,
> in the context of teaching, input() is, I believe, primarily used to
> extract a number from a string.  Thus, I would suggest that input
> should be replaced by something like
>
> def get_number(prompt):
>     s = raw_input(prompt)
>     try:
>         n = int(s)
>     except:
>         try:
>             n = float(s)
>         except:
>             print s + " is not a valid number."
>             return None
>     return n
>

There is _nothing_ untoward about allowing a beginner to use input as is. 
Input is most easily conceptualized as "allowing a user to type an expression 
at runtime" or as I like to call it a "delayed expression" (see earlier 
post). It's very easy to grasp that in a program I can write x = 3 or x 
= "foo" or x = [1,2,3]; if I want to replace the righthand side of that 
statement with input at runtime, I just do that: x = input("Enter a value for 
x: "). In other words, I am letting the user write the code. That's a simple 
concept; saying it's dangerous is just making the statement that "programming 
is dangerous". Of course it is! But that's exactly what we're giving our 
students the power to do: be dangerous by programming.

This proposal strips input of much of its power. I use input to get all kinds 
of data, not just numbers. It's a very expressive feature of Python, and it 
happens also to be padagogically useful. Proposals that turn input into some 
typed scanning statement ala Java (or C or C++ or Pascal) rob it of it's 
dynamic nature and make it unpythonic in my book. Python is  a dynamic 
language, let's keep dynamic input. 

I am more comfortable with Ian's proposal to only allow Python literals (not 
expressions), but now you've made input more complicated by putting 
restrictions on it. Why can't I enter exactly what I would put in the 
assignment statement if I were writing the code? I often fire up Python, type 
a little loop and use it to evaluate expressions as a calculator.

Perhaps I am tainted by my association with languages such as Lisp and Prolog 
that are beautiful for experimentation because they allow the freedom to 
intermingle programs and data. I would really miss input as a day-to-day user 
of Python, not just as an educator. I will have to carry my custom IO module 
with me and load it on every Python 3000 bearing computer I come across. What 
a pathetic waste of my time that will be. 

--Johnny Inputseed

ps. That's my last entry on this thread; I've got more pressing things to 
worry about right now. See Arthur, I do understand it's not a life or death 
issue :-).


> Otherwise, while I am not using Python in a classroom, I certainly
> agree with the summary below and support it.
>
> André
>
> > Core Python maintainers,
> >
> > Over on the Python edu-sig, we have been discussing a small aspect of PEP
> > 3100 and its effects on teaching and classroom use. What is at issue is
> > input() and raw_input(), which have been targeted for removal, and marked
> > [done]:
> >
> > http://www.python.org/dev/peps/pep-3100/
> >
> > Guido suggested in his 2002 "Python Regrets" talk that
> > eval(sys.stdin.readline()) and sys.stdin.readline() can be used for
> > these, respectively. That's not quite true of course, because they also
> > have a prompt. But even that aside, we believe that we would like to keep
> > them as-is.
> >
> > I think that we have consensus among (the teachers of edu-sig) that many
> > of us rely on the ease-of-use of the input() and raw_input() functions
> > for one simple reason: input() and raw_input() can be used on day-1 of
> > class, before discussing imports, streams,  strings, eval, or functions.
> > Complete replacement solutions require discussions of all of those
> > topics.
> >
> > We believe that their removal goes against the spirit of Python in the
> > classroom, and Python will be more complicated on the first day of class
> > because of it.
> >
> > There were some suggestions that there could be better names for them,
> > including "ask()" and "askexp()". In any event, we'd rather have them the
> > way they are than not at all. Of course it is easy to add as a site.py
> > implementation, but those of us that teach would rather use 100% Pure
> > Python.
> >
> > For the complete edu-sig discussion, see:
> >
> > http://mail.python.org/pipermail/edu-sig/2006-September/006967.html
> >
> > Thank you for considering leaving this as is,
> >
> > The Teachers of Python edu-sig
> >
> >
> > _______________________________________________
> > Edu-sig mailing list
> > Edu-sig at python.org
> > http://mail.python.org/mailman/listinfo/edu-sig
>
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> http://mail.python.org/mailman/listinfo/edu-sig

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