On 9/10/06, Hugh Stewart <[EMAIL PROTECTED]> wrote: > To cut to the chase: raw_input() provides an extremely useful > I/O function for simple exercise type problems which are so essential > in building a beginners repertoire of programming techniques and > for 'John Zeller' type problems ( simple quick dirty and effective > solutions that get those housekeeping jobs done).
This is where you lose me Hugh, and not because I disagree about 'John Zelle' type problems being useful. What I wouldn't necessarily do is make my palindrome finder a standalone script. A Python module usually contains more than just a single function, and everything you code and leave on the disk as a .py file is importable as such (as a module), even if you run it directly. The function to reverse a number might be reusable in another context. Functions are top level in Python. You can feed them to each other. In math class we teach about functions, usually with single-letter names -- usually considered poor practice in CS -- and we teach kids to feed arguments to these functions through mouth-looking pairs of parentheses. This is the kind of awareness I want a newbie to bring to a Python module (a .py file) -- me and those who share my particular outlook in this regard (I'm not speaking for the entire world here obviously). A .py file should be more like a fish tank, full of fun little performers that you gradually add to over time. No main() need tie it all together. It's a vocabulary. Life is full of 'em. We know kids have the mental capacity, e.g. from sports, to track lots of names. Someone objects: but how are you supposed to remember what all these functions do and what arguments they take? Well that's a good question, but how is saving a program named palindrome.py in some subdirectory any more self-explanatory, even if it raw_inputs? Where should we look for it? There should be more documentation -- the perrenial need (Apple fought against the "thick manual" aesthetic, recruited sensitive artist types to our previously drab dweeby field). The functional style is to feed functions through their mouths, not to "pipe in" through intravenous -- a hole right in the body of a function. What I don't like about making palindrome.py a "script" (a standalone .py file) is it fails to develop the sense of "being in a namespace", which is what you get when you fire up the Python shell and import one. Suddenly dir() shows there's more here than just the builltins, lots of little functions to feed, a whole fish tank of fun fishies, all with proper names, presumably with docstrings to explain 'em. My style of teaching beginners is: teach 'em to "feed the fish" i.e. to use functional notation (probably already familiar from math class). Use Python's dir() and help() facilities to remind oneself, or explore for the first time, what's in a .py file. Python modules are far better at self-documenting that brute file systems at the OS level. It's easier to document palindrome( ) in funprograms.py, than it is to save palindrome.py and stuff text in some readme.txt. And we start coding "creatures" right away too. A barking Dog, right away -- maybe something the teacher writes, projected on the big screen. But at least we see it, understand the dot in mydog.bark(3) is invoking an internal bark method. Because modules are just naturally habitates for such class definitions. This is a really big part of the language, not some bolted-on after thought. OO is where it's at. Not some "OO is 2nd year CS2 stuff" (like you're joking right? -- you're *not* the world, right? (praise Allah we have these alternative approaches)). What's *in* a .py file may be a whole lot of Zelle-like short programs, a box of chocolates, none of them more than 20 or so lines. Maybe they call each other sometimes. palindrome() invokes reverseme() etc. An ecology. Stuff depending on other stuff. Another way of saying it: treat Python's shell, plus a code editor, as your working environment. You tweak the source, save, and reload(). This is the work cycle when debugging for example. If you never drop out to the OS the entire hour, so what? It's *not*: run python myscript.py from the terminal window, prompt myself for input, see the thing crash, then go open a text editor to mess with the code. That's *too hard* (unnecessarily hard). All that work in the OS. Why are we messing with the OS so directly? That's a whole different shell, not Python's. Not suitable for beginners, to be mixing OS and Python shells too much. Entirely different namespaces. Too schizo. > Python gives us a programming language of extraordinary productivity > at all levels of programming (especially for beginners). I completely agree. But we shouldn't confuse pedagogy with starting level of sophistication. My beginning students know as little programming as anyone, and have bell curved abilities. But give I fly the CP4E banner, I'm goal directed towards a culture where the caste line between being "a programmer" and "not a programmer" is of fading significance. Students stream in from biology to learn enough Python to go off and write little models, make graphs, study DNA sequencing or whatever. That's just what biologists do, as well as squint through microscopes and/or trap mosquitos and/or culture microbes. This isn't about "becoming a career programmer" at this level, it's about learning to use a computer as one more tool of the trade. I think the "make everything a raw_input script" philosophy harkens back to the days when you had these people called "programmers" who looked at source code a lot, and other people called "users" who never did. Pre CP4E. A very dark age. A huge chasm or wall separated these two psychologies, and when you trained to become a programmer, you needed to internalize this chasm and imagine yourself as a "dumb user" who never looks at source code or has any awareness of namespaces. You had to divide yourself mentally in this way so that you'd be better able to work with the *real* (as in actual, true to life) dumb users in the future (the people you'd meet on the job). I'm saying that's not the CP4E way. We're training *you* to code for *you* right at first, with no prehistorical "dumb users" in the picture. You maybe haven't committed to becoming a computer programmer professionally. You just want to be able to code, like any red blooded American or Russian or Indonesian or whatever. Like driving a car. Like knowing how to swim. A basic skill. Part of numeracy, just like ordinary algebra, already required for a high school degree. You're going to become fluent in the Python environment, productive, and we're not going to introduce you to "scripting" until a little later, when we start to explore the sys module, including sys.args -- the infrastructure for interfacing with the OS outside of Python. That's somewhat advanced, and that's when we get to sys.stdin.readline() as well. We're not just "feeding the fish" in a Python module fish tank from the Python shell anymore, we're doing more sysop type stuff. Now we're more into "scripts" as in "grep through /etc/users/myclubhouse and find out who hasn't paid dues in awhile" -- little maintenance jobs customarily executed from a terminal window, written in Perl, Python, Ruby or whatever. That's one use for 'em, but it's a specialized niche, more for CS majors than biology majors. But anyway when it comes to sysop type stuff, if there're arguments to be passed, we usually just use POSIX switches and sys.arg infrastructure, passing a file name if there's a ton of input to consider. Once again sys.stdin.readline() is a bit on the obscure side. But it's there, in case you need it for some reason. Kirby _______________________________________________ Edu-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/edu-sig
