On Sep 13, 4:59 pm, [EMAIL PROTECTED] (Michael R. Copeland) wrote: > Yes, I could fire up the interactive mode and play with some > statements...but I consider that sort of thing for programming > neophytes or experimenting with specific issues.
To misquote Francis Bacon, "you would have fish, but dare not get your fingernails dirty." Back in '62-minus, when you started programming, there was no such thing as "just dive in and try stuff." Imagine if someone had said, "Just punch some random holes in this computer card and feed it in - you'll get the hang of it," you would have thought they were crazy. So you probably read a whole bunch of books first, before you punched your very first card, and then stood in line to feed your deck to the card reader on "the mainframe," then waited anywhere from 15 minutes to an hour or more to get your job output. The length of this cycle was itself a deterrent to interactive experimentation - you had to *know* what you were doing and do it right, or risk wasting an hour because you accidentally punched a character in column 6 instead of column 7. In fact, much of the software development process from that era was oriented around avoiding as many needless compile/run cycles as possible. Well, in 45+ years, things have progressed a bit. Nowadays, I don't pore over my code looking for that stray or missing brace or closing paren - the compiler will tell me in about 3 seconds where these syntax errors are. And so too with Python. Do "neophytes" just dive in and try stuff? What of it? You have chosen a nice simple little problem space, well within the fairway of the vanilla, batteries-included Python. In your noobiness you might write some code that duplicates the features of a standard built-in module, but so what? Isn't your goal to learn the language as well as the libraries? And you would not be the first (nor the last) to post a question to this group along the lines of "can you look at this code and see what I'm doing wrong?" and get back the answer of "what you're doing wrong is writing your own code instead of just using standard module X" - it happens to many newcomers and nearly all survive this early trauma. Just because I can convert a list of data into a histogram in a single line of code if I use itertools.groupby, doesn't invalidate my learning how to do it in 4 lines with a defaultdict, or 6 lines with an explicit for loop. In your shoes, I would pursue a minimalist approach, learning the basic language features, and then browsing through the standard lib docs to get familiar with the available modules. Get a no-frills IDE with a short learning curve - I like SciTE for this, although there is no auto-completion - to help automate your code/run cycle (note: just code/run, no compile step!). I also suggest you go to the Python.org wiki and look for the documentation for experienced programmers who are starting to switch over to Python (http://wiki.python.org/moin/ BeginnersGuide/Programmers) - others have trod this path before, and some have left bread crumbs behind. Best of luck! -- Paul -- http://mail.python.org/mailman/listinfo/python-list
