I'm glad you went to the work to make this a PEP. That's the way to go!
I've interpersed my own views for the record, about why I think
raw_input should go away.
However, if I lose this little battle, I really won't mind too much.
I don't think the success CP4E depends on it strongly, one way or the
other.
> This PEP proposes that Python 3.0 retains some simple user input capability,
> equivalent to raw_input(), within the built-in namespace.
In our intro classes, we have to import any namespace beyond what's in
__builtins__ and beyond we've written during the session.
Even if the target namespace in turns contains raw_input(), we still
had to import that target program.
Running Python programs from the command line is not the optimum place
to begin with beginners, in our view.
So we don't see the problem with importing sys.stdin.readline() if
that's what our script is going to need.
But "scripts" are not where we begin.
A lot of the time, we simply feed arguments to functions
interactively, in the context of a Python shell session.
This approach, we feel, develops a stronger understanding of Python in
our students, so we're glad raw_input is being demoted.
That will discourage pedagogy which considers command line scripts
from the operating system a beginner's environment.
>
> Motivation
> ==========
>
> With its easy readability and its support for many programming styles
> (e.g. procedural, object-oriented, etc.) among others, Python is perhaps
> the best computer language to use in introductory programming classes.
> Simple programs most often need to contain a means to provide information to
> a user (output) as well as obtaining information from that user (input).
> Any computer language intended to be used in an educational setting should
> provide straightforward methods for both input and output.
>>> def f(x): return x*x
>>> f(2)
4
is in not way "not straightforward". Input and output have both occured.
> The current proposals for Python 3.0 [1] include a simple output pathway
> via a built-in function named print(), but a more complicated method for
> input [e.g. via sys.stdin.readline()], one that requires importing an external
> module. Current versions of Python (pre-3.0) include raw_input() as a
> built-in
> function. With the availability of such a function, programs that
> require simple
> input/output can be written from day one, without requiring discussions of
> importing modules, streams, etc.
Modules, aka namespaces, should be discussed very early. The shell is
a boring place without import, a key word.
> raw_input() provides a simple mean to ask a question and obtain information
> from a user. The proposed plans for Python 3.0 would require the replacement
> of the single statement
>
> speed = raw_input("What is the average airspeed velocity of an unladed
> swallow?")
>
> by the more complicated
>
> import sys
> print("What is the average airspeed velocity of an unladed swallow?")
> speed = sys.stdin.readline()
However, if the source code is in front of you, self-prompting is less
of a temptation. Just enter the speed in the source code or feed it
to __init__.
myswallow.velocity = 10
> The removal of raw_input (or equivalent) would not significantly reduce the
> built-in namespace while it would steepen significantly the learning
> curve for beginners.
Especially if they're being taught the old fashioned way, based on
*not* being in the shell and trying to write "scripts" for
hypothetical end users who have no access to the source.
In sum, raw_input() is mostly used as a crutch by those wedding to a
particular pedagogical technique.
Whereas I believe teachers have a right to develop their own style, I
don't believe it's "the beginners" who are being protected by keeping
raw_input as a __builtin__; in this case, I believe it's more teachers
trying to stick to their old ways of teaching.
Alternatives exist.
Beginners need not suffer if raw_input goes to sys. i/o is not such a
problem when you know how to work with a namespace directly.
Kirby
_______________________________________________
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig
