"Steve Holden" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > 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 -- http://mail.python.org/mailman/listinfo/python-list
