How to Start

[Paul McGuire]

On Sep 13, 4:59 pm, mrc2... at cox.net (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