Python is pretty easy to install on Windows, but sometimes you need to do a few extra tweaks to really get the most our your development environment. In this article, we will try to cover all the common things you might want to do or install to get an ideal Python Windows development workspace set up. Some of you might think that all you need to do is install Python and you’re done, but if you’re going to do Windows development, then you’ll need a few other packages to make it nicer.

Installing and Configuring Python

Download Python and run the installer. Make sure you got the version you want (i.e. Python 2.7 or 3.x). You’ll also want to make sure you get the bit type you want as there’s a 32-bit and a 64-bit version. Note: The 32-bit Python will run just fine on a 64-bit system, but not vice versa! Once you’ve got that installed, we’ll move on.

Now we’re going to make sure Python is set up right. Open a command window by going to Start –> Run and then typing “cmd” and pressing enter or return. Try typing “python” (without the quotes) in there and hitting your enter key. If you see the Python shell, then we’re halfway there. It should look something like this:

If you don’t, then we need to modify some settings.

Modifying Your Path

On Windows, it can help a LOT to modify your Path settings by adding your Python path and the path to the Scripts folder to your System Path. Here’s one way that you can do it:

1. Right-Click “My Computer” and choose Properties (Windows XP) or you may have to go digging in Control Panel on Windows 7 and do a “Show All Control Panel Items” from the path bar and look for System. You should see something like this:

   

2. Go to the Advanced tab and press the Environmental Variable button to see something like the following:

   

3. You will see two types of variables here. In the bottom section are System Variables. Scroll down to the one labeled Path and at the end of that, add the following two lines: ;C:\Python26;C:\Python26\Scripts (adjust as necessary according to your version of Python and its location) Note that each entry is separated by a semi-colon, so make sure you do that too or this will not work!

Now you should be able to run Python from the command line. Not only that, you’ll also be able to run the special scripts that were in Python’s Scripts folder. Why would you care? Well, if you install easy_install / SetupTools or pip, they will install stuff in the Scripts folder that you can run. Speaking of which, since you now have a brand new installation of Python, let’s take a moment to show you how to install a 3rd party package.

How to Install a Package on Windows

We will use pip as our example. It is used for the easy installation of Python packages from the Python Packages Index (PyPI, not to be confused with PyPy). Anyway, you’ll need to go here to download it. The pip package is in a tarred and gzipped download at the bottom of the page. You’ll probably need something like IZArc or Filzip to unzip it since Windows doesn’t unzip tar files natively.

Open up a command line window as you did before. Now you will need to use the “cd” command to change directories to the location that you unzipped the files to. This can take some practice. On my machine, I usually unzip to my desktop and just cd there and then into the unzipped package. Once you’re in the folder that has the setup.py file in it, all you need to do to install it is to type the following:


python setup.py install


Most of the time, this works great and the package is installed correctly. Occasionally, you will run into certain packages that complain that they need a compiler. If you don’t have one installed (like Visual Studio or MingW), then you won’t be able to install the package this way. You will have to find a pre-packaged installer for it. On my machine, I usually have easy_install installed too. For some reason, the package is called SetupTools . Anyway, the main reason that you used to need easy_install was that it was the defacto standard for install Python Eggs, which you can read about here or here. Now you can use pip or distribute to do the same thing. All three can also install packages that are in compressed archives. Normally, all you have to do to install a package with one of these utilities is something like this:


easy_install PackageName
pip install PackageName


Read their respective docs for more information though.

Other Handy Packages for Windows Developers

If you are a serious Windows developer who will need access to Windows APIs, then you will require the PyWin32 package. You’ll want to become familiar with ctypes too, but that’s been included with Python since version 2.5. PyWin32 is a lightweight wrapper around the Windows APIs. You can actually look on MSDN for the API documentation and almost directly translate it into Python. The ctypes package put on an even lower level and can be used to interact with DLLs directly, among many other things.

Another common need when programming on Windows is access to Window Management Instrumentation (WMI). Fortunately, Tim Golden has written a nice wmi module. You can usually get the same information using PyWin32, but it’s more convoluted than just using WMI. Tim Golden has also written several other utilities:

• WinSys – Python tools for the Windows Administrator
• winshell – a utility for getting Windows paths easily
• An Active Directory wrapper

You should also check out his awesome “How Do I” series of tutorials.

Finally, Python includes a module called _winreg that you can use to gain access to the Windows Registry. It’s a very powerful tool that’s very useful if you do a lot of administrative scripting on Windows.

Other Python Installations for Windows

The comments section started filling up with people mentioning the special Python installations you can get that actually include PyWin32 and other packages all wrapped up in one installer. That is also an option. Here are a few of those:

• PythonXY – This one includes a TON of other packages, including PyWin32, SciPy, wxPython, NumPy and dozens of others. It looks like a jack of all trades. I have not used this one, but it sounds interesting.
• The Enthought Python Distribution – That link is their paid version, but there’s also a lightweight free version available too.
• ActivePython from ActiveState – this one has been around for a long time and includes the PyWin32 documentation and various other tools.

Wrapping Up

You should now have all the tools you need to be an effective Windows developer with Python. If you need help, the PyWin32 and ctypes mailing lists are active and they have experts there that can answer just about anything you’d want to know about those packages.

Further Reading

• A Python Windows Registry tutorial
• Some other article on MvP about Windows and Python
• Official Python documentation on Windows
• Another tutorial on Python on Windows
• PyWin32 documentation from ActiveState

TurboGears is one of several web frameworks for Python that are available. The most popular by far is Django. Where I work, we chose TurboGears because of its integration with SQLAlchemy which supports composite keys. At that time, Django did not support that feature and I am not sure if it does yet. Anyway, I develop almost exclusively on a Windows box and have found the TurboGears’ documentation on the subject a little confusing. So here’s how I do it.

Note: We’ll be using TurboGears 2.1 in this tutorial

Getting Started

We’re going to make sure Python is set up right first. Open a command window by going to Start –> Run and then typing “cmd” and pressing enter. Try typing “python” (without the quotes) in there and hitting your enter. If you see the Python shell, then we’re halfway there. If you don’t, then we need to modify some settings.

Modifying Your Path

On Windows, I have found that it helps a LOT to modify my Path settings by adding my Python path and the path to the Scripts folder to my Path. Here’s how you do it:

1. Right-Click “My Computer” and choose Properties (Windows XP) or you may have to go digging in Control Panel on Windows 7 and do a “Show All Control Panel Items” from the path bar and look for System. You should see something like this:

   

2. Go to the Advanced tab and press the Environmental Variable button to see something like the following:

   

3. You will see two types of variables here. In the bottom section are System Variables. Scroll down to the one labeled Path and at the end of that, add the following two lines: ;C:\Python26;C:\Python26\Scripts (adjust as necessary according to your version of Python and its location) Note that each entry is separated by a semi-colon, so make sure you do that too or this will not work!

Installing Prerequisites

Once that’s done, we need to make sure you have SetupTools installed. Go to the Python Package Index and download it if you know you don’t already have it as SetupTools will install a little script known as easy_install that will make getting TurboGears setup a breeze. Just scroll to the end of the page and pick the exe that corresponds to your Python version. You cannot install an egg unless you already have this installed, so I don’t know why they have eggs on there to begin with.

Once that’s done, open a new command window and try typing in the following: easy_install. You should receive an error like this: “error: No urls, filenames, or requirements specified (see –help)” If you do, then you’ve got it installed and on your path. Good job!

The TurboGears people recommend installing virtualenv to help keep your primary Python installation (PyPI) as pristine as possible. It also helps when you need to experiment with different versions of software that you don’t want to break current projects. How does this work? Well, virtualenv creates a little virtual workspace for you on your machine where it puts a copy of Python and installs all the software into that virtual place for you to play with. It’s a development sandbox! Since you now have easy_install, we’ll use that to install it. In your command window, type: easy_install virtualenv

That will cause easy_install to go out on the internet and try to download and install virtualenv from PyPI. It should look something like this:

If it completed successfully, then we’re ready to create a virtual environment for our TurboGears install. Change directories to a location that you’d like to do this in. On Windows 7, you’ll probably have security issues if you try to do this outside of your Documents or similar Collections folders, so you should stick with one of those. For this tutorial, we’ll create it in My Documents.

Once you’re there, type the following: virtualenv –no-site-packages example

This will create a folder that’s labeled “example” with several folders inside it. You should see the following on your screen:

The –no-site-packages command will prevent the virtual environment from inheriting anything from the system Python’s site-packages folder. Now change directory into your example folder in the command window and type the following: Scripts\activate.bat (see screenshot below)

Installing & Setting Up TurboGears

Now your virtual environment is active and ready to rock. You can tell because each line is now prefixed with the name of the folder you’re in, which in this case is “example”. You can install Turbogears at this point as your virtual environment also has Setup Tools installed. However, this install is a little different as we will be specifying a specific URL. Type the following (you may want to check the TurboGears website to see if the URL has been updated since the writing of this post):


easy_install.exe -i http://www.turbogears.org/2.1/downloads/current/index tg.devtools


Depending on the speed of your PC and your connection, this will take a while. TurboGears is a mashup of a large number of 3rd party Python packages. You can watch it install or you can go get a drink or make a phone call while you wait. Once that’s finished, we’re nearly done.

Note: All the packages should be installing to your virtual space’s lib folder, NOT your default Python’s. If the latter is happening, you probably don’t have the virtual environment activated

Creating a TurboGears Workspace

One of the packages we installed earlier was Python Paste. TurboGears uses this package to bootstrap a new TurboGears application. So in your activated virtual environment, type the following command:


paster quickstart example


Note: If your path to the “example” folder has a space in it, you will receive an error about needing the PyWin32 library installed. Very annoying.

When you run this, you will need to answer 3 questions. The first is what to name the project. The default is the same name as the folder. Note that the project name has to be in lowercase. Then it asks if you’d like to use Mako templates. What it doesn’t say is that if you choose no (which is the default), you will get Genshi templates instead. That’s up to you. Mako looks and feels more “pythonic” from what I’ve seen of it, so I’d recommend it unless you already know Genshi or something like Genshi. The last question is whether or not you want authentication, which will give you a simple admin interface that you can login to, the default of which is “yes”. You can experiment with these or just take the defaults.

The next step is to change directories into your new project directory and then type the following in at the command line:


python setup.py develop


This adds your project to the virtual environment and also downloads a few packages to install alongside it that might be useful in your development. I don’t really know how these help you, but it seems to be a requirement of sorts according to TurboGear’s documentation.

The next to last step is to input the following into your command line window:


paster setup-app development.ini


This will initiate your database, which is basically just creating and populating with some default information for the security / authentication you agreed to. If you didn’t install that stuff or don’t want to run this step, you don’t have to. But you won’t be able to login unless you do.

Finally, you need to type the following:


paster serve development.ini


Now you will have a fully functioning website that’s running on http://localhost:8080/ (or http://127.0.0.1:8080) . If you load up your browser and navigate to that you should see something like this:

Wrapping Up

Now you should know how to install and setup a TurboGears web application. The sky’s the limit after all that work. You’ll need to start reading the documentation, add a dash of javascript and a bit of CSS and you’ll have a cool website in no time. Good luck and have fun!

Last week, there was an interesting thread on the PyWin32 mailing list about how to read Microsoft Access databases with Python without having Access actually installed. Vernon Cole had the solution, but I noticed that Google doesn’t seem to index the PyWin32 list very well, so I decided to write about it here.

I took his code and modified it slightly to make it even more explicit and I put together a lame database file with Microsoft Access XP (downloadable below). The adodbapi module’s (not to be confused with the adodb module) source distribution also includes a test database in its “test” folder that you can use as well. Anyway, here’s the code:

import adodbapi
 
database = "db1.mdb"
constr = 'Provider=Microsoft.Jet.OLEDB.4.0; Data Source=%s'  % database
tablename = "address"
 
# connect to the database
conn = adodbapi.connect(constr)
 
# create a cursor
cur = conn.cursor()
 
# extract all the data
sql = "select * from %s" % tablename
cur.execute(sql)
 
# show the result
result = cur.fetchall()
for item in result:
    print item
 
# close the cursor and connection
cur.close()
conn.close()

This code was tested on the following:

• Windows XP Professional with Python 2.5.4 and adodbapi 2.4.0 with Microsoft Access installed
• Windows 7 Home Premium (32-bit) with Python 2.6.4, adodbapi 2.2.6, without Microsoft Access

Downloads

• adodbapi_access.zip

A couple of months ago at work, we received a report that a file was locked. The dialog that appeared showed the initials of a user who wasn’t even working for us any more. Thus we discovered an annoying bug that can crop up with Office. Basically, a user is asked by Word or Excel to input their name and initials during the first run of that respective application and it will keep that data no matter who logs into the machine later on. This can lead to some serious confusion when we get error messages of this sort. Anyway, let’s take a quick look at how to get this done.

We will be using Python’s _winreg module for this hack. You can see said hack below:

from _winreg import *
 
key = CreateKey(HKEY_CURRENT_USER,
                r'Software\Microsoft\Office\11.0\Common\UserInfo')
res = QueryValueEx(key, "UserInitials")
print repr (res)
 
username = u"mldr\0"
SetValueEx(key, "UserInitials", 0, REG_BINARY, username)
CloseKey(key)

Here we use the CreateKey method just in case the key doesn’t already exist. If the key does exist, then CreateKey will just open it. The first half of the script was used for checking to see if the key had the correct value in it. The last three lines overwrite the value with my initials. I can’t remember why I had to make a unicode string, but the guys on PyWin32 told me that was the way to do it. I can tell you that I wasn’t ever able to get a plain string to work. Once the value is set, we clean up after ourselves by closing the key.

That’s it! Easy, eh? Have fun with Python!

Update (10/12/2010) – One of my alert readers told me that SqlAlchemy 0.6.x currently does NOT support the Access dialect. Read here for more info.

A year or two ago, I was asked to transfer some data from some old Microsoft Access files to our Microsoft SQL Server. Since I enjoy using SqlAlchemy, I decided to see if it supported Access. The documentation at the time was pretty unhelpful in this regard, but it did seem to be possible and I found one thread about it on SqlAlchemy’s Google group.

The code to connect to Microsoft Access is pretty simple. It goes something like this:

from sqlalchemy import create_engine
engine = create_engine(r'access:///C:/some/path/database.MDB')

See how easy that was? You just tell SqlAlchemy what kind of database to connect to, add three forward slashes and then the path to the file. Once that’s done, you can do pretty much anything with the Access file that you can do with a normal database:

########################################################################
class TableName(Base):
    """
    MS Access database
    """
    __tablename__ = "ROW"
    __table_args__ = ({"autoload":True})  # load the database
    FILENUM = Column("FILE #", Integer, key="FILENUM")

In the code above, I use SqlAlchemy’s declarative syntax to autoload the database’s structure. I can’t recall is this database had its primary key set, but I’m guessing it didn’t since I had to add that last line.

Anyway, once you have your connection, you can just run queries as you normally would. In my case, I ended up creating a model file to hold all the table definitions for the Access file and the SQL Server database, then I did a SELECT * on the Access file, looped over the result and inserted each row into the SQL Server one. The only thing you have to watch out for is that Access is a lot more forgiving of NULLS than SQL Server is, so I had to write some special handling around that atrocity.

Well, that’s really all there is to it. You can check out my other SqlAlchemy tutorials for more general information about using SqlAlchemy to interact with your database.

The other day, I was tasked with finding a way to get a list of all running processes on a Windows XP virtual machine. I was also supposed to include information about how much CPU and memory each process used. Fortunately, this didn’t have to be a remote script, but one that could be run on the client. After a fair bit of Googling here and there, I finally found a solution. In this article, we’ll look at some of the rejects as well as the eventual solution, which happens to work cross-platform.

One of the first scripts I found was this one back from March of 2006:

# http://mail.python.org/pipermail/python-win32/2006-March/004340.html
import win32com.client
wmi=win32com.client.GetObject('winmgmts:')
for p in wmi.InstancesOf('win32_process'):
    print p.Name, p.Properties_('ProcessId'), \
        int(p.Properties_('UserModeTime').Value)+int(p.Properties_('KernelModeTime').Value)
    children=wmi.ExecQuery('Select * from win32_process where ParentProcessId=%s' %p.Properties_('ProcessId'))
    for child in children:
        print '\t',child.Name,child.Properties_('ProcessId'), \
            int(child.Properties_('UserModeTime').Value)+int(child.Properties_('KernelModeTime').Value)

This script requires the PyWin32 package to work. However, while it’s a handy little script, it doesn’t show anything that I want except the ProcessId. I don’t really care about the user or kernel mode times (i.e. the total CPU time by user or kernel). Also I don’t really like working with the black magic of COM, so I ended up rejecting this one out of hand.

Next up was an ActiveState recipe. It looked promising:

# http://code.activestate.com/recipes/303339-getting-process-information-on-windows/
import win32pdh, string, win32api
 
def procids():
    #each instance is a process, you can have multiple processes w/same name
    junk, instances = win32pdh.EnumObjectItems(None,None,'process', win32pdh.PERF_DETAIL_WIZARD)
    proc_ids=[]
    proc_dict={}
    for instance in instances:
        if instance in proc_dict:
            proc_dict[instance] = proc_dict[instance] + 1
        else:
            proc_dict[instance]=0
    for instance, max_instances in proc_dict.items():
        for inum in xrange(max_instances+1):
            hq = win32pdh.OpenQuery() # initializes the query handle 
            path = win32pdh.MakeCounterPath( (None,'process',instance, None, inum,'ID Process') )
            counter_handle=win32pdh.AddCounter(hq, path)
            win32pdh.CollectQueryData(hq) #collects data for the counter 
            type, val = win32pdh.GetFormattedCounterValue(counter_handle, win32pdh.PDH_FMT_LONG)
            proc_ids.append((instance,str(val)))
            win32pdh.CloseQuery(hq)
 
    proc_ids.sort()
    return proc_ids
 
print procids()

Alas, while this also got me a list of processes from my Windows box (along with the PID), it didn’t give me any information on the CPU and memory utilization. I think this one could work if I used different counter names. I’m guessing if you wanted, you could figure out that information using MSDN. I didn’t want to mess with that, so I continued digging.

That recipe led me to the following one based on ctypes:

# http://code.activestate.com/recipes/305279/
 
"""
Enumerates active processes as seen under windows Task Manager on Win NT/2k/XP using PSAPI.dll
(new api for processes) and using ctypes.Use it as you please.
 
Based on information from http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q175030&ID=KB;EN-US;Q175030
 
By Eric Koome
email ekoome@yahoo.com
license GPL
"""
from ctypes import *
 
#PSAPI.DLL
psapi = windll.psapi
#Kernel32.DLL
kernel = windll.kernel32
 
def EnumProcesses():
    arr = c_ulong * 256
    lpidProcess= arr()
    cb = sizeof(lpidProcess)
    cbNeeded = c_ulong()
    hModule = c_ulong()
    count = c_ulong()
    modname = c_buffer(30)
    PROCESS_QUERY_INFORMATION = 0x0400
    PROCESS_VM_READ = 0x0010
 
    #Call Enumprocesses to get hold of process id's
    psapi.EnumProcesses(byref(lpidProcess),
                        cb,
                        byref(cbNeeded))
 
    #Number of processes returned
    nReturned = cbNeeded.value/sizeof(c_ulong())
 
    pidProcess = [i for i in lpidProcess][:nReturned]
 
    for pid in pidProcess:
 
        #Get handle to the process based on PID
        hProcess = kernel.OpenProcess(PROCESS_QUERY_INFORMATION | PROCESS_VM_READ,
                                      False, pid)
        if hProcess:
            psapi.EnumProcessModules(hProcess, byref(hModule), sizeof(hModule), byref(count))
            psapi.GetModuleBaseNameA(hProcess, hModule.value, modname, sizeof(modname))
            print "".join([ i for i in modname if i != '\x00'])
 
            #-- Clean up
            for i in range(modname._length_):
                modname[i]='\x00'
 
            kernel.CloseHandle(hProcess)
 
if __name__ == '__main__':
    EnumProcesses()

This is pretty clever looking, but I’m pretty bad at parsing ctypes. It’s something I want to learn, but I had a deadline, doggone it! Plus this one only showed a list of running processes but no information about them. Fortunately, the author included a reference, but I decided to keep looking.

Next I found a thread about using Tim Golden’s handy WMI module to do this sort of thing (below is copied right from the thread):

# http://mail.python.org/pipermail/python-win32/2003-December/001482.html
>>> processes = WMI.InstancesOf('Win32_Process')
>>> len(processes)
41
>>> [process.Properties_('Name').Value for process in processes] # get
the process names
[u'System Idle Process', u'System', u'SMSS.EXE', u'CSRSS.EXE',
u'WINLOGON.EXE', u'SERVICES.EXE', u'LSASS.EXE', u'SVCHOST.EXE',
u'SVCHOST.EXE', u'SVCHOST.EXE', u'SVCHOST.EXE', u'SPOOLSV.EXE',
u'ati2evxx.exe', u'BAsfIpM.exe', u'defwatch.exe', u'inetinfo.exe',
u'mdm.exe', u'rtvscan.exe', u'SCARDSVR.EXE', u'WLTRYSVC.EXE',
u'BCMWLTRY.EXE', u'EXPLORER.EXE', u'Apoint.exe', u'carpserv.exe',
u'atiptaxx.exe', u'quickset.exe', u'DSentry.exe', u'Directcd.exe',
u'vptray.exe', u'ApntEx.exe', u'FaxCtrl.exe', u'digstream.exe',
u'CTFMON.EXE', u'wuauclt.exe', u'IEXPLORE.EXE', u'Pythonwin.exe',
u'MMC.EXE', u'OUTLOOK.EXE', u'LineMgr.exe', u'SAPISVR.EXE',
u'WMIPRVSE.EXE']
 
Here is how to get a single process and get its PID.
 
>>> p = WMI.ExecQuery('select * from Win32_Process where
Name="Pythonwin.exe"')
>>> [prop.Name for prop in p[0].Properties_] # let's look at all the
process property names
[u'Caption', u'CommandLine', u'CreationClassName', u'CreationDate',
u'CSCreationClassName', u'CSName', u'Description', u'ExecutablePath',
u'ExecutionState', u'Handle', u'HandleCount', u'InstallDate',
u'KernelModeTime', u'MaximumWorkingSetSize', u'MinimumWorkingSetSize',
u'Name', u'OSCreationClassName', u'OSName', u'OtherOperationCount',
u'OtherTransferCount', u'PageFaults', u'PageFileUsage',
u'ParentProcessId', u'PeakPageFileUsage', u'PeakVirtualSize',
u'PeakWorkingSetSize', u'Priority', u'PrivatePageCount', u'ProcessId',
u'QuotaNonPagedPoolUsage', u'QuotaPagedPoolUsage',
u'QuotaPeakNonPagedPoolUsage', u'QuotaPeakPagedPoolUsage',
u'ReadOperationCount', u'ReadTransferCount', u'SessionId', u'Status',
u'TerminationDate', u'ThreadCount', u'UserModeTime', u'VirtualSize',
u'WindowsVersion', u'WorkingSetSize', u'WriteOperationCount',
u'WriteTransferCount']
>>> p[0].Properties_('ProcessId').Value # get our ProcessId
928

This is some cool stuff and I use Golden’s modules in some of my other code. However, I was still uncertain as to which counters to use to get to my information. I thought most of this stuff would just be coded for me or something! Well, it turned out that there is a package out there that does exactly what I needed AND it works on all the three of the major platforms! Amazing!

The Cross-Platform Solution!

The package’s name is psutil and it was what I decided to use. Here’s what I ended up with:

import os
import psutil
import time
 
logPath = r'some\path\proclogs'
if not os.path.exists(logPath):
    os.mkdir(logPath)
 
separator = "-" * 80
format = "%7s %7s %12s %12s %30s, %s"
format2 = "%7.4f %7.2f %12s %12s %30s, %s"
while 1:
    procs = psutil.get_process_list()
    procs = sorted(procs, key=lambda proc: proc.name)
 
    logPath = r'some\path\proclogs\procLog%i.log' % int(time.time())
    f = open(logPath, 'w')
    f.write(separator + "\n")
    f.write(time.ctime() + "\n")
    f.write(format % ("%CPU", "%MEM", "VMS", "RSS", "NAME", "PATH"))
    f.write("\n")
 
    for proc in procs:
        cpu_percent = proc.get_cpu_percent()
        mem_percent = proc.get_memory_percent()
        rss, vms = proc.get_memory_info()
        rss = str(rss)
        vms = str(vms)
        name = proc.name
        path = proc.path
        f.write(format2 % (cpu_percent, mem_percent, vms, rss, name, path))
        f.write("\n\n")
    f.close()
    print "Finished log update!"
    time.sleep(300)
    print "writing new log data!"

Yes, it’s an infinite loop and yes, that’s usually a very bad thing to do (except in GUI programming). However, for my purpose, I needed a way to check the user’s processes every 5 minutes or so to see what was causing the machine to act so weird. Thus, the script needs to run forever and log the results to uniquely named files. That’s all this script does, along with a little formatting magic. Feel free to use it or not as you see fit.

I hope you found this collection of material helpful. Hopefully it will save you all the digging I went through!

Note: While this last script appears to work just fine on Windows XP, on Windows 7 32 and 64-bit, you will get an “Access Denied” traceback, I suspect this is caused by Window 7′s increased security, but I will try to find a workaround.

UPDATE (10/09/2010) – The psutil folks don’t know why it doesn’t work, but one of their developers has confirmed the issue. You can follow along on their Google Groups list.

After about a year or so at my current job, as we were still working on upgrading the last few Windows 98 machines to Windows XP, we had a need to check which machines on our network were getting low on disk space. The issue was cropping up because we had Windows XP loaded on several machines that had 10 GB hard drives and a few with 20 GB and one or two with just 4 GB. Anyway, after some digging online, I discovered that the PyWin32 package could accomplish what I needed.

Here is the code that I used:

import win32com.client as com
 
def TotalSize(drive):
    """ Return the TotalSize of a shared drive [GB]"""
    try:
        fso = com.Dispatch("Scripting.FileSystemObject")
        drv = fso.GetDrive(drive)
        return drv.TotalSize/2**30
    except:
        return 0
 
def FreeSpace(drive):
    """ Return the FreeSpace of a shared drive [GB]"""
    try:
        fso = com.Dispatch("Scripting.FileSystemObject")
        drv = fso.GetDrive(drive)
        return drv.FreeSpace/2**30
    except:
        return 0
 
workstations = ['computeNameOne']
print 'Hard drive sizes:'
for compName in workstations:
    drive = '\\\\' + compName + '\\c$'
    print '*************************************************\n'
    print compName
    print 'TotalSize of %s = %f GB' % (drive, TotalSize(drive))
    print 'FreeSpace on %s = %f GB' % (drive, FreeSpace(drive))
    print '*************************************************\n'

Note at the bottom that I used a list. Normally, I would list the computer names of every computer that I wanted to check. Then I would iterate over those names and put together the right path that I needed from a machine with full domain admin rights.

To get this to work, we needed to import win32com.client and call the following: com.Dispatch(“Scripting.FileSystemObject”). This would get us a COM object that we could query to get a disk object. Once we had that, we can ask the disk how much total space it had and how much free space. Looking at this code today, I would combine the two functions into one and return a tuple. As you can see, I do a little bit of math on the result to get it to return the size in gigabytes.

That’s all there is to it. Simple stuff. I suspect that I didn’t write this code completely since the variable names suck. It is probably from an ActiveState recipe or a forum and I forgot to attribute it. If you recognize the code, let me know in the comments!

The bbfreeze package also allows us to create binaries, but only on Linux and Windows. It’s just an easy_install away, so if you plan on following along with the examples in the article, you should go get it. The bbfreeze package includes egg support, so it can include egg dependencies in your binary, unlike py2exe. You can also freeze multiple scripts at once, include the Python interpreter and more. According to bbfreeze’s PyPI entry, it’s only been tested with Python 2.4-2.5, so keep that in mind. However, I was able to use it with Python 2.6 with no obvious problems.

Getting Started with bbfreeze

You can use easy_install to download and install bbfreeze or you can just download its source or the egg file directly from the Python Package Index (PyPI). In this article, we’ll try using it on a simple configuration file generator script and we’ll also try it against a lame wxPython program. My test machine was a Windows 7 Home Edition 32-bit laptop with bbfreeze 0.96.5, and Python 2.6.4. Let’s start with the configuration script:

# config_1.py
import configobj
 
#----------------------------------------------------------------------
def createConfig(configFile):
    """
    Create the configuration file
    """
    config = configobj.ConfigObj()
    inifile = configFile
    config.filename = inifile
    config['server'] = "http://www.google.com"
    config['username'] = "mike"
    config['password'] = "dingbat"
    config['update interval'] = 2
    config.write()
 
#----------------------------------------------------------------------
def getConfig(configFile):
    """
    Open the config file and return a configobj
    """
    return configobj.ConfigObj(configFile)
 
def createConfig2(path):
    """
    Create a config file
    """
    config = configobj.ConfigObj()
    config.filename = path
    config["Sony"] = {}
    config["Sony"]["product"] = "Sony PS3"
    config["Sony"]["accessories"] = ['controller', 'eye', 'memory stick']
    config["Sony"]["retail price"] = "$400"
    config.write()
 
if __name__ == "__main__":
    createConfig2("sampleConfig2.ini")

This script has a couple of functions that are pointless, but we’ll leave them in for illustrative purposes. According to the bbfreeze documentation, we should be able to create a binary with the following string typed into the command line:


bb-freeze config_1.py


This assumes that you have “C:\Python26\Scripts” on your path. If you don’t, you’ll need to type the complete path out (i.e. “C:\Python26\Scripts\bb-freeze config_1.py”). When I ran this, I got an error. Here it is:

Traceback (most recent call last):
  File "C:\Python26\Scripts\bb-freeze-script.py", line 8, in <module>
    load_entry_point('bbfreeze==0.96.5', 'console_scripts', 'bb-freeze')()
  File "C:\Python26\lib\site-packages\bbfreeze-0.96.5-py2.6-win32.egg\bbfreeze\__init__.py", line 18, in main
    f()
  File "C:\Python26\lib\site-packages\bbfreeze-0.96.5-py2.6-win32.egg\bbfreeze\freezer.py", line 474, in __call__
    self.addModule("encodings.*")
  File "C:\Python26\lib\site-packages\bbfreeze-0.96.5-py2.6-win32.egg\bbfreeze\freezer.py", line 411, in addModule
    self.mf.import_hook(name[:-2], fromlist="*")
  File "C:\Python26\lib\site-packages\bbfreeze-0.96.5-py2.6-win32.egg\bbfreeze\modulegraph\modulegraph.py", line 256, in import_hook
    modules.update(self.ensure_fromlist(m, fromlist))
  File "C:\Python26\lib\site-packages\bbfreeze-0.96.5-py2.6-win32.egg\bbfreeze\modulegraph\modulegraph.py", line 345, in ensure_fromlist
    fromlist.update(self.find_all_submodules(m))
  File "C:\Python26\lib\site-packages\bbfreeze-0.96.5-py2.6-win32.egg\bbfreeze\modulegraph\modulegraph.py", line 369, in find_all_submodules
    for (path, mode, typ) in ifilter(None, imap(moduleInfoForPath, names)):
NameError: global name 'ifilter' is not defined

It would seem that the “modulegraph.py” file is missing an import from the itertools library, which is included with Python. I edited my copy of “modulegraph.py” to include the following line at the top of the file: “from itertools import ifilter”. This got rid of that traceback, but it raised another because “imap” wasn’t defined either. To fix the second error, I changed my import to “from itertools import ifilter,imap” and then it ran with no problems and produced a binary in a “dist” folder along with nine other files (see screenshot below).

Using bbfreeze’s Advanced Configuration

The PyPI page for bbfreeze (which is also its home page) has very little documentation. However, the page does say that the preferred way to use bbfreeze is with little scripts. We’re going to try using creating a binary with the lame wxPython, mentioned earlier. Here’s the wx code:

import wx
 
########################################################################
class DemoPanel(wx.Panel):
    """"""
 
    #----------------------------------------------------------------------
    def __init__(self, parent):
        """Constructor"""
        wx.Panel.__init__(self, parent)
 
        labels = ["Name", "Address", "City", "State", "Zip",
                  "Phone", "Email", "Notes"]
 
        mainSizer = wx.BoxSizer(wx.VERTICAL)
        lbl = wx.StaticText(self, label="Please enter your information here:")
        lbl.SetFont(wx.Font(12, wx.SWISS, wx.NORMAL, wx.BOLD))
        mainSizer.Add(lbl, 0, wx.ALL, 5)
        for lbl in labels:
            sizer = self.buildControls(lbl)
            mainSizer.Add(sizer, 1, wx.EXPAND)
        self.SetSizer(mainSizer)
        mainSizer.Layout()
 
    #----------------------------------------------------------------------
    def buildControls(self, label):
        """"""
        sizer = wx.BoxSizer(wx.HORIZONTAL)
        size = (80,40)
        font = wx.Font(12, wx.SWISS, wx.NORMAL, wx.BOLD)
 
        lbl = wx.StaticText(self, label=label, size=size)
        lbl.SetFont(font)
        sizer.Add(lbl, 0, wx.ALL|wx.CENTER, 5)
        if label != "Notes":
            txt = wx.TextCtrl(self, name=label)
        else:
            txt = wx.TextCtrl(self, style=wx.TE_MULTILINE, name=label)
        sizer.Add(txt, 1, wx.ALL, 5)
        return sizer
 
 
 
########################################################################
class DemoFrame(wx.Frame):
    """
    Frame that holds all other widgets
    """
 
    #----------------------------------------------------------------------
    def __init__(self):
        """Constructor"""
        wx.Frame.__init__(self, None, wx.ID_ANY,
                          "cxFreeze Tutorial",
                          size=(600,400)
                          )
        panel = DemoPanel(self)
        self.Show()
 
#----------------------------------------------------------------------
if __name__ == "__main__":
    app = wx.App(False)
    frame = DemoFrame()
    app.MainLoop()

Now let’s create a simple freezing script!

# bb_setup.py
from bbfreeze import Freezer
 
f = Freezer(distdir="bb-binary")
f.addScript("sampleApp.py")
f()

First off, we import the Freezer class from the bbfreeze package. Freezer accepts three arguments: a destination folder, an includes iterable and an excludes iterable (i.e. a tuple or list). Just to see how well bbfreeze works with only its defaults, we leave out the includes and excludes tuples/lists. Once you have a Freezer object, you can add your script(s) by calling the Freezer object name’s addScript method. Then you just need to call the object (i.e. f() ). If you do all that, you should end up with a 14.5 MB folder holding 18 files. When I ran the sampleApp.exe file, it ran just fine and was properly themed, however it also had a console screen. To figure out the correct syntax, I used GUI2Exe. Here’s the new code:

# bb_setup2.py
from bbfreeze import Freezer
 
includes = []
excludes = ['_gtkagg', '_tkagg', 'bsddb', 'curses', 'email', 'pywin.debugger',
            'pywin.debugger.dbgcon', 'pywin.dialogs', 'tcl',
            'Tkconstants', 'Tkinter']
 
bbFreeze_Class = Freezer('dist', includes=includes, excludes=excludes)
 
bbFreeze_Class.addScript("sampleApp.py", gui_only=True)
 
bbFreeze_Class.use_compression = 0
bbFreeze_Class.include_py = True
bbFreeze_Class()

If you run this, you should end up with a “dist” folder that contains 18 files and is 16.6 MB in size. Notice that we added a second argument to the addScript method: gui_only=True. This makes that annoying console go away. We also set compression to zero (no compression, I think) and include the Python interpreter. Turning on compression only reduced the result down to 14.3 MB though.

The bbfreeze package also handles “recipes” and includes several examples, however they are not documented well either and I couldn’t figure out how to include them with my current examples. Feel free to figure them out on your own!

Wrapping Up

Well, now you should know the basics of using bbfreeze to create binaries from your programs. I hope you found this helpful. The last article in this series will be on GUI2Exe. Look for it soon!

In our previous article on building binaries, we learned a little about py2exe. This time around, we will be focusing our collective attention on the ins and outs of PyInstaller. We’ll use the same lame wxPython script from the last article for one of our examples, but we’ll also try a normal console script to see what the differences are, if any. In case you didn’t know, PyInstaller works on Linux, Windows and Mac (experimental) and works with Python 1.5-2.6 (except on Windows, where there’s a caveat for 2.6 – see below). PyInstaller supports code-signing (Windows), eggs, hidden imports, single executable, single directory, and lots more!

Getting Started with PyInstaller

Note on Python 2.6 on Windows: If you read the PyInstaller website closely, you will see a warning about Python 2.6+ not being fully supported. The note says that you will currently need to have the Microsoft CRT installed for your executable to work. What this is probably referring to is the side-by-side assemblies / manifest issues that were introduced with Python 2.6 vis-a-vis Microsoft Visual Studio 2008. We already mentioned this problem in the first article. If you don’t know anything about it, please check out the py2exe website, the wxPython wiki or Google for the issue.

Anyway, let’s get on with the show. After you download PyInstaller, you just unzip the archive somewhere convenient. The follow these three simple steps:

1. Run Configure.py to save some basic configuration data to a “.dat” file. This saves some time since PyInstaller won’t have to recalculate the configuration on the fly.
2. Run the following command on the command line: python Makespec.py [opts] where scriptname is the name of the main Python file you use to run your program.
3. Finally, run the following command via the command line: python Build.py specfile to build your executable.

Let’s run through this with a real script now. We’ll start with a simple console script that creates a faux configuration file. Here’s the code:

import configobj
 
#----------------------------------------------------------------------
def createConfig(configFile):
    """
    Create the configuration file
    """
    config = configobj.ConfigObj()
    inifile = configFile
    config.filename = inifile
    config['server'] = "http://www.google.com"
    config['username'] = "mike"
    config['password'] = "dingbat"
    config['update interval'] = 2
    config.write()
 
#----------------------------------------------------------------------
def getConfig(configFile):
    """
    Open the config file and return a configobj
    """
    return configobj.ConfigObj(configFile)
 
def createConfig2(path):
    """
    Create a config file
    """
    config = configobj.ConfigObj()
    config.filename = path
    config["Sony"] = {}
    config["Sony"]["product"] = "Sony PS3"
    config["Sony"]["accessories"] = ['controller', 'eye', 'memory stick']
    config["Sony"]["retail price"] = "$400"
    config.write()
 
if __name__ == "__main__":
    createConfig2("sampleConfig.ini")

Now let’s make a spec file:


c:\Python25\python c:\Users\Mike\Desktop\pyinstaller-1.4\Makespec.py config_1.py


On my test machine, I have 3 different Python versions installed, so I had to specify the Python 2.5 path explicitly (or set Python 2.5 as the default). Anyway, this should create a file similar to the following (which was named “config_1.spec”):

# -*- mode: python -*-
a = Analysis([os.path.join(HOMEPATH,'support\\_mountzlib.py'), os.path.join(HOMEPATH,'support\\useUnicode.py'), 'config_1.py'],
             pathex=['C:\\Users\\Mike\\Desktop\\py2exe_ex', r'C:\Python26\Lib\site-packages'])
pyz = PYZ(a.pure)
exe = EXE(pyz,
          a.scripts,
          exclude_binaries=1,
          name=os.path.join('build\\pyi.win32\\config_1', 'config_1.exe'),
          debug=False,
          strip=False,
          upx=True,
          console=True )
coll = COLLECT( exe,
               a.binaries,
               a.zipfiles,
               a.datas,
               strip=False,
               upx=True,
               name=os.path.join('pyInstDist2', 'config_1'))

For the Python script we’re using, we need to add an explicit path to the location of configobj.py in the Analysis section of the spec file in the pathex parameter. If you do not do this, when you run the resulting executable, it will open and close a console window really fast and you won’t be able to tell what it says unless you run the exe from the command line. I did the latter to find out what was wrong and discovered it could not find the configobj module. You can also specify the output path for your exe in the COLLECT function’s name parameter. In this case, we put PyInstaller’s output in the “config_1″ subfolder of “pyInstDist2″, which should be a folder alongside your original script. There are a ton of options when configuring your spec file, which you can read about here.

To build the executable based on the spec file, do the following on the command line:


c:\Python25\python c:\Users\Mike\Desktop\pyinstaller-1.4\Build.py config_1.spec


On my machine, I ended up with a folder that had 25 files in it that totaled 6.7 MB. You should be able to reduce the size using the Analysis section’s excludes parameter and/or compression.

PyInstaller and wxPython

Now let’s try creating a binary from a simple wxPython script. Here’s the Python script:

import wx
 
########################################################################
class DemoPanel(wx.Panel):
    """"""
 
    #----------------------------------------------------------------------
    def __init__(self, parent):
        """Constructor"""
        wx.Panel.__init__(self, parent)
 
        labels = ["Name", "Address", "City", "State", "Zip",
                  "Phone", "Email", "Notes"]
 
        mainSizer = wx.BoxSizer(wx.VERTICAL)
        lbl = wx.StaticText(self, label="Please enter your information here:")
        lbl.SetFont(wx.Font(12, wx.SWISS, wx.NORMAL, wx.BOLD))
        mainSizer.Add(lbl, 0, wx.ALL, 5)
        for lbl in labels:
            sizer = self.buildControls(lbl)
            mainSizer.Add(sizer, 1, wx.EXPAND)
        self.SetSizer(mainSizer)
        mainSizer.Layout()
 
    #----------------------------------------------------------------------
    def buildControls(self, label):
        """"""
        sizer = wx.BoxSizer(wx.HORIZONTAL)
        size = (80,40)
        font = wx.Font(12, wx.SWISS, wx.NORMAL, wx.BOLD)
 
        lbl = wx.StaticText(self, label=label, size=size)
        lbl.SetFont(font)
        sizer.Add(lbl, 0, wx.ALL|wx.CENTER, 5)
        if label != "Notes":
            txt = wx.TextCtrl(self, name=label)
        else:
            txt = wx.TextCtrl(self, style=wx.TE_MULTILINE, name=label)
        sizer.Add(txt, 1, wx.ALL, 5)
        return sizer
 
 
 
########################################################################
class DemoFrame(wx.Frame):
    """
    Frame that holds all other widgets
    """
 
    #----------------------------------------------------------------------
    def __init__(self):
        """Constructor"""
        wx.Frame.__init__(self, None, wx.ID_ANY,
                          "PyInstaller Tutorial",
                          size=(600,400)
                          )
        panel = DemoPanel(self)
        self.Show()
 
#----------------------------------------------------------------------
if __name__ == "__main__":
    app = wx.App(False)
    frame = DemoFrame()
    app.MainLoop()

Since this is a GUI, we’ll create our spec file slightly differently:


c:\Python25\python c:\Users\Mike\Desktop\pyinstaller-1.4\Makespec.py -F -w sampleApp.py


Note the -F and -w parameters. The -F command tells PyInstaller to create just one executable whereas the -w tells PyInstaller to hide the console window. Here’s the resulting spec file:

# -*- mode: python -*-
a = Analysis([os.path.join(HOMEPATH,'support\\_mountzlib.py'), os.path.join(HOMEPATH,'support\\useUnicode.py'), 'sampleApp.py'],
             pathex=['C:\\Users\\Mike\\Desktop\\py2exe_ex'])
pyz = PYZ(a.pure)
exe = EXE( pyz,
          a.scripts,
          a.binaries,
          a.zipfiles,
          a.datas,
          name=os.path.join('pyInstDist', 'sampleApp.exe'),
          debug=False,
          strip=False,
          upx=True,
          console=False )

Note that the last line has the “console” parameter set to “False”. If you build this like you did with the console script you should end up with one file in the “pyInstDist” folder that is approximately 7.1 MB in size.

Wrapping Up

This ends our quick tour of PyInstaller. I hope you found this helpful in your Python binary-making endeavors. There is much more information on the PyInstaller website and it’s pretty well documented, although the website is pretty plain. Be sure to give it a try and see just how much easy PyInstaller is to use!

Note: I tested all this using PyInstaller 1.4 and Python 2.5 on Windows 7 Home Premium (32-bit).

Further Reading

• PyInstaller Official Website, Manual, Mailing List
• First article in the “Build a Binary Series”

I received a request to create an article on how to use py2exe and wxPython to create an executable. I d, ecided to do a series on packaging instead. It is my intention to go over the major Windows binary building utilities and show you, dear reader, how to use them to create a binary that you can distribute. Once those articles are done, I’ll show how to use Inno and NSIS. To kick things off, we’ll go over how to use py2exe, probably the most popular of the Windows executable packages.

Let’s Get Started

For this tutorial, we’re going to use a wxPython script that doesn’t do anything. This is a contrived example, but we’re using wx to make it more visually interesting than just doing a console “Hello World” program. Note also that I am using py2exe 0.6.9, wxPython 2.8.11.0 and Python 2.6. Here’s what the end product should look like when run:

Now that we know what it looks like, here’s a look at the code:

import wx
 
########################################################################
class DemoPanel(wx.Panel):
    """"""
 
    #----------------------------------------------------------------------
    def __init__(self, parent):
        """Constructor"""
        wx.Panel.__init__(self, parent)
 
        labels = ["Name", "Address", "City", "State", "Zip",
                  "Phone", "Email", "Notes"]
 
        mainSizer = wx.BoxSizer(wx.VERTICAL)
        lbl = wx.StaticText(self, label="Please enter your information here:")
        lbl.SetFont(wx.Font(12, wx.SWISS, wx.NORMAL, wx.BOLD))
        mainSizer.Add(lbl, 0, wx.ALL, 5)
        for lbl in labels:
            sizer = self.buildControls(lbl)
            mainSizer.Add(sizer, 1, wx.EXPAND)
        self.SetSizer(mainSizer)
        mainSizer.Layout()
 
    #----------------------------------------------------------------------
    def buildControls(self, label):
        """"""
        sizer = wx.BoxSizer(wx.HORIZONTAL)
        size = (80,40)
        font = wx.Font(12, wx.SWISS, wx.NORMAL, wx.BOLD)
 
        lbl = wx.StaticText(self, label=label, size=size)
        lbl.SetFont(font)
        sizer.Add(lbl, 0, wx.ALL|wx.CENTER, 5)
        if label != "Notes":
            txt = wx.TextCtrl(self, name=label)
        else:
            txt = wx.TextCtrl(self, style=wx.TE_MULTILINE, name=label)
        sizer.Add(txt, 1, wx.ALL, 5)
        return sizer
 
 
 
########################################################################
class DemoFrame(wx.Frame):
    """
    Frame that holds all other widgets
    """
 
    #----------------------------------------------------------------------
    def __init__(self):
        """Constructor"""
        wx.Frame.__init__(self, None, wx.ID_ANY,
                          "Py2Exe Tutorial",
                          size=(600,400)
                          )
        panel = DemoPanel(self)
        self.Show()
 
#----------------------------------------------------------------------
if __name__ == "__main__":
    app = wx.App(False)
    frame = DemoFrame()
    app.MainLoop()

This is fairly straightforward, so I’ll leave it the reader to figure out. This article is about py2exe after all.

The py2exe setup.py file

The key to any py2exe script is the setup.py file. This file controls what gets included or excluded, how much we compress and bundle, and much more! Here is the simplest setup that we can use with the wx script above:

from distutils.core import setup
import py2exe
 
setup(windows=['sampleApp.py'])

As you can see, we import the setup method from distutils.core and then we import py2exe. Next we call setup with a windows keyword parameter and pass it the name of the main file inside a python list object. If you were creating a non-GUI project, than you would use the console key instead of windows. To run this, open up a command prompt and navigate to the appropriate location. Then type “python setup.py py2exe” to run it. This is what I got when I first ran it:

It looks like wxPython requires the “MSVCP90.dll” and Windows can’t find it. A quick Google search yielded the consensus that I needed the “Microsoft Visual C++ 2008 Redistributable Package”, found here. I downloaded it, installed it and tried py2exe again. Same error. This would have probably worked had I been using Visual Studio to create an exe of a C# program. Anyway, the trick was to search the hard drive for the file and then copy it to Python’s DLL folder, which on my machine was found at the following location: C:\Python26\DLLs (adjust as necessary on your machine). Once the DLL was in the proper place, the setup.py file ran just fine. The result was put into a “dist” folder which contains 17 files and weighs in at 15.3 MB. I double-clicked the “sampleApp.exe” file to see if my shiny new binary would work and it did! In older versions of wxPython, you would have needed to include a manifest file to get the right look and feel (i.e the themes), but that was taken care of in 2.8.10 (I think) as was the side-by-side (SxS) assembly manifest file that used to be required.

Note that for non-wxPython scripts, you will probably still need to mess with the SxS manifests and all the hoops that includes. You can read more about that in the py2exe tutorial.

Creating an Advanced setup.py File

Let’s see what other options py2exe gives us for creating binaries by creating a more complex setup.py file.

from distutils.core import setup
import py2exe
 
includes = []
excludes = ['_gtkagg', '_tkagg', 'bsddb', 'curses', 'email', 'pywin.debugger',
            'pywin.debugger.dbgcon', 'pywin.dialogs', 'tcl',
            'Tkconstants', 'Tkinter']
packages = []
dll_excludes = ['libgdk-win32-2.0-0.dll', 'libgobject-2.0-0.dll', 'tcl84.dll',
                'tk84.dll']
 
setup(
    options = {"py2exe": {"compressed": 2,
                          "optimize": 2,
                          "includes": includes,
                          "excludes": excludes,
                          "packages": packages,
                          "dll_excludes": dll_excludes,
                          "bundle_files": 3,
                          "dist_dir": "dist",
                          "xref": False,
                          "skip_archive": False,
                          "ascii": False,
                          "custom_boot_script": '',
                         }
              },
    windows=['sampleApp.py']
)

This is pretty self-explanatory, but let’s unpack it anyway. First we set up a few lists that we pass to the options parameter of the setup function.

• The includes list is for special modules that you need to specifically include. Sometimes py2exe can’t find certain modules, so you get to manually specify them here.
• The excludes list is a list of which modules to exclude from your program. In this case, we don’t need Tkinter since we’re using wxPython. This list of excludes is what GUI2Exe will exclude by default.
• The packages list is a list of specific packages to include. Again, sometimes py2exe just can’t find something. I’ve had to include email, PyCrypto, or lxml here before. Note that if the excludes list contains something you’re trying to include in the packages or includes lists, py2exe may continue to exclude them.
• dll_excludes – excludes dlls that we don’t need in our project.

In the options dictionary, we have a few other options to look at. The compressed key tells py2exe whether or not to compress the zipfile, if it’s set. The optimize key sets the optimization level. Zero is no optimization and 2 is the highest. The bundle_files key bundles dlls in the zipfile or the exe. Valid values for bundle_files are: 3 = don’t bundle (default) 2 = bundle everything but the Python interpreter 1 = bundle everything, including the Python interpreter. A couple of years ago, when I was first learning py2exe, I asked on their mailing list what the best option was because I was having issues with bundle option 1. I was told that 3 was probably the most stable. I went with that and stopped having random problems, so that’s what I currently recommend. If you don’t like distributing more than one file, zip them up or create an installer. The only other option I use in this list is the dist_dir one. I use it to experiment with different built options or to create custom builds when I don’t want to overwrite my main good build. You can read about all the other options (including ones not even listed here) on the py2exe website. By setting optimize to 2, we can reduce the size of folder by about one megabyte.

Reducing a wxPython Script’s Binary Size

There’s a thread on the wxPython mailing list about reducing the size of the binary. I contacted Steven Sproat, one of the people in the thread, about what he did and here’s the trick: Set the “bundle_files” option to 1 and the the zipfile to None. The result will be three files in your dist folder: MSVCR71.dll, sampleApp.exe and w9xpopen.exe. The size of the folder is 5.94 MB on my machine (Tested on a Windows XP machine). As I mentioned earlier, setting bundle_files to 1 can cause some users to experience issues when running your application, but this may have been fixed with the newer versions of py2exe. Here’s what the setup.py file looks like with the new options set:

from distutils.core import setup
import py2exe
 
includes = []
excludes = ['_gtkagg', '_tkagg', 'bsddb', 'curses', 'email', 'pywin.debugger',
            'pywin.debugger.dbgcon', 'pywin.dialogs', 'tcl',
            'Tkconstants', 'Tkinter']
packages = []
dll_excludes = ['libgdk-win32-2.0-0.dll', 'libgobject-2.0-0.dll', 'tcl84.dll',
                'tk84.dll']
 
setup(
    options = {"py2exe": {"compressed": 2,
                          "optimize": 2,
                          "includes": includes,
                          "excludes": excludes,
                          "packages": packages,
                          "dll_excludes": dll_excludes,
                          "bundle_files": 1,
                          "dist_dir": "dist",
                          "xref": False,
                          "skip_archive": False,
                          "ascii": False,
                          "custom_boot_script": '',
                         }
              },
    zipfile = None,
    windows=['sampleApp.py']
)

Another way to reduce the size of the folder is to use compression programs as one of my readers, ProgMan, pointed out. Here are his results:

Wrapping Up

You now know the basics for creating binaries with py2exe. I hope you have found this helpful for your current or future projects. If so, let me know in the comments!

Further Reading

• The py2exe Tutorial
• Packaging wxPyMail for Distribution
• GUI2Exe
• wxPython wiki page on py2exe