Request for feedback on my first Python program

[Chad Netzer]

On Fri, 2003-05-30 at 17:44, Scott Meyers wrote:

>   - I'm used to a compiler complaining if I reference a variable without
>     declaring it.  Python doesn't do this, nor can I find mention of some
>     kind of warning mode that will cause it to do it.

As a follow up to what Eric said, it is not uncommon to see people
initialize the most important variables or attributes to a default
value, and then reassign it later.  As you know, in C++ it has become
common to declare variables right before you first use them (as opposed
to the beginning of a function).  Well in Python, the variable names
aren't associated with a type, and so don't require that initialization.

The lack of declarations give us a bit more time to think up good
variable names. :)

>   I've also read a
>     tiny little bit about pyChecker.  Is it common to use such tools, or do
>     real Python programmers go bareback?

I go usually bareback, because PyChecker wasn't around when I started. 
But it is helpful for the occasional typo, and many other buglets not
associated with design.

>   - Is it better to get into the habit of (a) importing modules and using
>     fully qualified names or (b) importing selective names from modules and
>     using them without qualification?

Aha!  Well, I like to think of it as this.  If the module is providing a
number of related services, and I need many of them, I tend to import
it, and access its methods.

ie.

import math
math.sqrt()

If it is more of a container for a grab-bag of functions, and I need
only a few, I import the ones I need.

ie.

from math import sqrt

Well, actually, I got tricky there, because math can go either way. :)


Note that you can easily bind new names to module members for shortcuts,
when you need them.

ie.  I may do an "import math" and use its functions.  But then I have a
function that uses a math function a lot (say sqrt()).  I can easily
make the sqrt() local, without having to change my other code.

ie.
import math

def some_function():

   # I use sqrt() a lot, and don't want to always type math.sqrt()
   sqrt = math.sqrt

   # Now I can use sqrt() as if I had done "from math import sqrt"


So, it is a personal style thing, but over the years I find myself
tending to import the module, rather than it's functions.  Less
namespace pollution.  I make shortcut names when I need them.

Note that, due to implementation issues (mainly), if you want to use a
function in a loop, it is faster to make it a local variable to avoid
the module lookup on each iteration:

ie:

import math

# I use sqrt() in the loop, and want to gain a little bit of speed
sqrt = math.sqrt

for i in range(1000):
   sqrt(i)


That is faster than if I had done:

for i in range(1000):
   math.sqrt(i)


These kind of micro-optimizations are kind of going out of favor, as the
implementations(s) gain in performance (and computers gain even more). 
You should to local rebinding more for code clarity and style, then
speed.


> Finally, my ultimate goal with this project is to read a list of file and
> directory names from a file, create an archive (e.g., zip file) containing
> copies of the specified files and directories, encrypt the archive, and ftp
> it to a remote machine.  I've found libraries for working with zip files
> and for doing ftping, but I didn't see any standard library for encryping a
> file.  Is there one?

Not really any "standard" one (ie shipped with the standard sources),
mainly due to the normal concerns with distributing encryption
implementations.  But PyCrypto is commonly used and available, and their
a number of other implementations (some done wholly in Python.)

>   Also, a cursory glance at the zipfile module
> documentation didn't reveal a way to add the contents of a directory
> (recursively -- including all its subdirectories and files) to a zip file.
> Did I overlook something?

You could use os.path.walk().  It calls a user function with each
pathname in a directory tree.  You function then adds that path for the
zipfile.

The cookbook also has a "walktree" generator, with some additional
flexibility.

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/161542

-- 

Chad Netzer
(any opinion expressed is my own and not NASA's or my employer's)