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@brynmawr.edu <dblank@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@python.org http://mail.python.org/mailman/listinfo/edu-sig
_______________________________________________ Edu-sig mailing list Edu-sig@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@wartburg.edu (319) 352-8360