guy keren wrote: >>I'm sure I am - that was more than 20 years ago. And I don't think there >>were any libraries to speak of... >> >> > >actually, there were third-party libraries even in the old BASIC days - >they were just not called by that name. > > > For the Sinclair ZX81? I would have probably considered it a waste of my precious 1Kb RAM (including video memory) :-)
<-- snip snip --> >> 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]) ). >> >> > >i'm not going to use the interpreter for writing actual things. only for >testing very simple expressions. we're not in BASIC days any longer - and >thanks goodness for that ;) > > If you reread my description (27/10), you'll see I was not suggesting you do that - interpreter replaces shell, not editor. i.e.: you mainly call functions, type one-liners (mainly for trying out stuff before pasting and reediting in your file), end execfile. Functions, fancy loops and big if-else blocks go directly in the editor. This way, at each point you can call each function seperately and see what happens. <-- snip snip --> >> 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 don't think i'll even mention execfile - i'll just show how to do simple >stuff in the interpreter, and the rest using scripts. > > > execfile is an important cornerstone in the work-method I'm describing (p.s.: an alternative some people use is writing modules and importing them, but I find it does not work well until your source is stable and functioning - to some very experienced pythoners it might be fine, but surely not in our case). It takes about 20 seconds to explain what it does (by far simpler to explain than "chmod +x script.py; ./script.py" and that #! line). Of course if you choose to do it the "traditional way" (editor+shell), you wouldn't need it. But do take notice that if you avoid execfile you lose *most* of the advantages that people on this list have been talking highly about, so the added value of using the interpreter will seem much lower than it's potential >>No - not efficiency - instructive power and ease of use (my specific >>efficiency-related comment (keystrokes...) was clearly marked as >>directed to argumentative list readers). >> >> > >instructive power - probably. ease of use? that's a matter of taste, no >more. > > > Is help(file) easier, or looking up the file constructor in the python reference manual? Is typing f.re<tab> easier, or searching the list of available methods to discover readline? Might be a matter of taste, but some tastes are much more common in the general population... <-- snip snip --> >>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. >> >> > >actually, i don't see why. i usually have one terminal with an editor, and >another terminal in which i run the script. the work it takes in this >setup is no more (sometimes even less) then using a single interactive >interpreter session. the editor is much more convenient for editing then >the interactive prompt, for me. > > For most other people too. Again: interpreter<-->shell, editor<-->editor the work to setup: if you know how to setup a shell, just type "python" in 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. >> >> > >this is the problem - the interpreter will never behave like the shell. it >canbe "close" - but it's still a seperate environment. i don't want to >concentrate on this. > > Depends how you define environment. The user input frontend *is* identical. Both bash and python use readline(3) for that. If you are an advanced user, both read the same ~/.inputrc file. The only difference is minor default configuration values. That's one of the reasons why I was recommending to turn on the 'tab: complete' binding. The language backend is different. But - the language backend for the interpreter is python, which your'e gonna teach anyway...
