guy keren wrote: >i think you're forgetting what it was like when you first learned how to >write programs - using 3rd-party libraries is something you do after you >master the basics of the language. and you have to begin with learning to >use simple things first. > > I'm sure I am - that was more than 20 years ago. And I don't think there were any libraries to speak of...
You are probably right - probably better to do manual processing than a new lib. Just keep it short and simple - tedious manual argparsing might be even more boring. Also, as other people had been saying, you can completely avoid the subject by using the interpreter, at least for the cases where a script would require tedious parsing (I mean anything more than n=int(sys.argv[1]) ). >no, i will not tell them this is the way to go - i don't want to spoil >them to a level that they'll require re-adapting in order to learn C (or >other compiled langauges) next year. > > That's what I ment by saying that writing a script is an important skill (goal). If we stick to the idea of "simpler first", it might be good to start with demonstrating inside the interpreter, running longer code with 'execfile', then (one of the first lessons) show how to make it a script, with the motivation of wanting others to be able to run it "as a normal program" from the shell. >i want them to learn the concept of a program - not of an interactive >programming environment. python is a tools - not a means. thus, i don't >want to teach them everything that can be done in python - it's not real >interesting. those that will want that, will learn all the bits in the >future on their own. > >you should remember that what you achieve here is efficiency. this is not >relevant for a first programming course - there are more important skills >to learn first. it's like teaching touch-typing before teaching >programming, so they'll spend less time typing their programs - it's nice, >but realy not what they should learn first. > > No - not efficiency - instructive power and ease of use (my specific efficiency-related comment (keystrokes...) was clearly marked as directed to argumentative list readers). When you have an interpreter open during lecture (/exercise/demo/...) , and someone asks "why can't we just do x", or "what object does y refer to at this stage", you just type x or y (possibly pause to ask what do you think would happen now), then press enter... This is one *powerful* instructive tool. I don't think many poeple would bother to demonstrate these small things, if it means editing a new file (or "spoiling" the nice'n clean program they've been editing at the moment with debug messages), saving it, going back to the shell, and running it. Later, when they will be experimenting on their own, you'd want the interpreter to behave like the shell, so they would not have to learn two different environments. Since they *will* probably learn to hit tab to complete filenames in the shell, you'd certainly want it to work in the interpreter too. And it's a great help - you can quickly find out available function names and methods by just hitting tab - much more fun than using dir() or looking it up in the book. That is why I strongly recommend installing the 'tab: complete', as I suggested in the wiki.
