First practical Python code, comments appreciated

Paul McGuire ptmcg at austin.rr._bogus_.com
Wed Dec 14 15:15:33 CET 2005


"Steve Holden" <steve at holdenweb.com> wrote in message
news:mailman.2080.1134563479.18701.python-list at python.org...
> That form is non-portable. You might argue "I'm never going to run this
> program on anything other than Windows", and indeed for throwaway
> programs it's often easier to write something non-portable. It's
> surprising, though, how often you end up *not* throwing away such
> programs, so it can help to write portably from the start. I'd have used
>
>                newname = os.path.join(path,
>                               "%s_%s.%s" % (fname, pad, fext))
>                os.rename(os.path.join(s[0], oldname), newname)
>
> >             fcount = fcount + 1
> >
>
> Just a few pointers to make the script simpler, but your program is a
> very creditable first effort. Let us know what mistakes I made!
>

Just to chime in, and say that Steve's comments on portable programming have
to do with more than just your code running on other machines.  Developing
habits such as portable programming helps you to do these kinds of things
naturally, rather than to have to make a special effort if/when the issue
does come up.  Meanwhile, your portfolio of developed code reflects a
broader thinking span on your part, beyond just "let me whip together
something quick for the problem at hand."  When presenting your work, at a
conference or a job interview, it always helps to convey that you can see
the bigger picture.

Also, developing portable coding habits makes it easier for *you* to
assimilate code that others may have written for other platforms -
portability is an n-way street.  If you download some code fragment from
SourceForge, or from a tutorial, or a PyCon presentation, you will be less
likely to scratch your head over the purpose of os.join if you are in the
habit of using it already.

Otherwise, your code (with Steve's comments) is good, and it looks like it
does the job.  But I would also look over some tutorials, or examples of
existing code - Python comes with a huge set of sample code in the provided
libraries, and if you simply "self-teach" yourself, you can develop some bad
habits, and remain ignorant of some nice features and best practices.

Look at the use of native data structures (tuples, lists, and dicts), the
use of classes and class hierarchies, the uses of the module library, and
some of the relatively recent idioms of generators, list
comprehensions/generator expressions.  Look at the layout of the code to see
how the author broke the problem into manageable pieces.  Look for some of
the modules that crop up over and over again - not just sys, os, and math,
which are analogous to the C RTL, but also itertools, which I think is more
in the category of useful magic, like the C++ STL's <algorithm> module.

Look for object design concepts, such as containment and delegation, and ask
yourself how well they fit the problem for the given script.  If you are new
to object-oriented coding as well, read some of the free online Python
introductory texts, such as "Dive into Python" and "Think like a Computer
Scientist in Python," to learn how some of the object design idioms
translate to Python's type and language model.

Python expertise comes in a series of plateaus, over time and with practice.
It's a stimulating and rewarding journey, no matter which plateau you
reach - welcome to Python!

-- Paul





More information about the Python-list mailing list