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

[Andre Roberge]

On 9/8/06, John Zelle <john.zelle at wartburg.edu> wrote:
> 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.
>

And I certainly defer to John's greater experience in teaching Python
- so I rally to and support the viewpoint expressed by John below.
André

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