Installation

Reportlab supports most of the normal Python installation methods. You have the option of downloading the source and running “python setup.py install” or running a binary installer (on Windows). There was a recent thread on their mailing list that seemed to indicate that they may also support pip soon. The threads I’ve read about Reportlab’s support of easy_install are confusing, so I’m not sure if they already support that method or not.

Creating a Simple PDF

Reportlab has decent documentation. What I mean by that is that the documentation gives you just enough to get started, but when you find something slightly complex to do, you get to figure it out on your own. Just recently, they added a Code Snippets section to their website that will hopefully become a recipe book of cool tips and tricks and also help ameliorate this issue. But enough about that. Let’s see how to actually create something!

In Reportlab, the lowest-level component that’s used regularly is the canvas object from the pdfgen package. The functions in this package allow you to “paint” a document with your text, images, lines or whatever. I’ve heard some people describe this as writing in PostScript. I doubt it’s really that bad. In my experience, it’s actually a lot like using a GUI toolkit to layout widgets in specific locations. Let’s see how the canvas object works:

from reportlab.pdfgen import canvas
 
c = canvas.Canvas("hello.pdf")
c.drawString(100,750,"Welcome to Reportlab!")
c.save()

You should end up with a PDF that looks something like this:

The first thing to notice about this code is that if we want to save the PDF, we need to supply a file name to the Canvas object. This can be an absolute path or a relative path. In this example, it should create the PDF in the same location that you run the script from. The next piece of the puzzle is the drawString method. This will draw text wherever you tell it to. When using the canvas object, it starts at the bottom left of the page, so for this example, we told it to draw the string 100 points from the left margin and 750 points from the bottom of the page (1 point = 1/72 inch). You can change this default in the Canvas constructor by passing a zero to the bottomup keyword argument. However, I’m not exactly sure what will happen if you do that as the Reportlab user guide isn’t clear on this topic. I think it will change the start point to the top left though. The final piece in the code above is to save your PDF.

That was easy! You’ve just created a really simple PDF! Note that the default Canvas size is A4, so if you happen to be American, you’ll probably want to change that to letter size. This is easy to do in Reportlab. All you need to do is the following:

from reportlab.lib.pagesizes import letter
from reportlab.pdfgen import canvas
 
canvas = canvas.Canvas('myfile.pdf', pagesize=letter)
width, height = letter

The main reason to grab the width and height is that you can use them for calculations to decide when to add a page break or help define margins. Let’s take a quick look at the constructor for the Canvas object to see what other options we have:

def __init__(self,filename,
    pagesize=letter,
    bottomup = 1,
    pageCompression=0,
    encoding=rl_config.defaultEncoding,
    verbosity=0
    encrypt=None):

The above was pulled directly from the Reportlab User Guide, page 11. You can read about the other options in their guide if you want the full details.

Now let’s do something a little more complicated and useful.

A Little Form, Little Function

In this example, we’ll create a partial printable form. As far as I can tell, Reportlab doesn’t support the fillable forms that were added to Adobe products a few years ago. Anyway, let’s take a look at some code!

from reportlab.lib.pagesizes import letter
from reportlab.pdfgen import canvas
 
canvas = canvas.Canvas("form.pdf", pagesize=letter)
canvas.setLineWidth(.3)
canvas.setFont('Helvetica', 12)
 
canvas.drawString(30,750,'OFFICIAL COMMUNIQUE')
canvas.drawString(30,735,'OF ACME INDUSTRIES')
canvas.drawString(500,750,"12/12/2010")
canvas.line(480,747,580,747)
 
canvas.drawString(275,725,'AMOUNT OWED:')
canvas.drawString(500,725,"$1,000.00")
canvas.line(378,723,580,723)
 
canvas.drawString(30,703,'RECEIVED BY:')
canvas.line(120,700,580,700)
canvas.drawString(120,703,"JOHN DOE")
 
canvas.save()

This is based on an actual receipt I created at work. The main difference between this one and the previous example is the canvas.line code. You can use it to draw lines on your documents by passing two X/Y pairs. I’ve used this functionality to create grids, although it’s pretty tedious. Other points of interest in this code include the setLineWidth(.3) command, which tells Reportlab how thick or thin the line should be; and the setFont(‘Helvetica’, 12) command, which allows us to specify a specific font and point size.

Our next example will build on what we’ve learned so far, but also introduce us to the concept of “flowables”.

Going with the Flow

If you’re in advertising or do any kind of work with form letters, then Reportlab makes for an excellent addition to your arsenal. We use it to create form letters for people who have overdue parking tickets. The following example is based on some code I wrote for that application, although the letter is quite a bit different. (Note that the code below will not run without the Python Image Library)

import time
from reportlab.lib.enums import TA_JUSTIFY
from reportlab.lib.pagesizes import letter
from reportlab.platypus import SimpleDocTemplate, Paragraph, Spacer, Image
from reportlab.lib.styles import getSampleStyleSheet, ParagraphStyle
from reportlab.lib.units import inch
 
doc = SimpleDocTemplate("form_letter.pdf",pagesize=letter,
                        rightMargin=72,leftMargin=72,
                        topMargin=72,bottomMargin=18)
Story=[]
logo = "python_logo.png"
magName = "Pythonista"
issueNum = 12
subPrice = "99.00"
limitedDate = "03/05/2010"
freeGift = "tin foil hat"
 
formatted_time = time.ctime()
full_name = "Mike Driscoll"
address_parts = ["411 State St.", "Marshalltown, IA 50158"]
 
im = Image(logo, 2*inch, 2*inch)
Story.append(im)
 
styles=getSampleStyleSheet()
styles.add(ParagraphStyle(name='Justify', alignment=TA_JUSTIFY))
ptext = '<font size=12>%s</font>' % formatted_time
 
Story.append(Paragraph(ptext, styles["Normal"]))
Story.append(Spacer(1, 12))
 
# Create return address
ptext = '<font size=12>%s</font>' % full_name
Story.append(Paragraph(ptext, styles["Normal"]))
for part in address_parts:
    ptext = '<font size=12>%s</font>' % part.strip()
    Story.append(Paragraph(ptext, styles["Normal"]))
 
Story.append(Spacer(1, 12))
ptext = '<font size=12>Dear %s:</font>' % full_name.split()[0].strip()
Story.append(Paragraph(ptext, styles["Normal"]))
Story.append(Spacer(1, 12))
 
ptext = '<font size=12>We would like to welcome you to our subscriber base for %s Magazine! \
        You will receive %s issues at the excellent introductory price of $%s. Please respond by\
        %s to start receiving your subscription and get the following free gift: %s.</font>' % (magName,
                                                                                                issueNum,
                                                                                                subPrice,
                                                                                                limitedDate,
                                                                                                freeGift)
Story.append(Paragraph(ptext, styles["Justify"]))
Story.append(Spacer(1, 12))
 
 
ptext = '<font size=12>Thank you very much and we look forward to serving you.</font>'
Story.append(Paragraph(ptext, styles["Justify"]))
Story.append(Spacer(1, 12))
ptext = '<font size=12>Sincerely,</font>'
Story.append(Paragraph(ptext, styles["Normal"]))
Story.append(Spacer(1, 48))
ptext = '<font size=12>Ima Sucker</font>'
Story.append(Paragraph(ptext, styles["Normal"]))
Story.append(Spacer(1, 12))
doc.build(Story)

Well, that’s a lot more code than our previous examples contained. We’ll need to look over it slowly to understand everything that’s going on. When you’re ready, just continue reading.

The first part that we need to look at are the new imports:

from reportlab.lib.enums import TA_JUSTIFY
from reportlab.platypus import SimpleDocTemplate, Paragraph, Spacer, Image
from reportlab.lib.styles import getSampleStyleSheet, ParagraphStyle
from reportlab.lib.units import inch

From enums, we import “TA_JUSTIFY”, which allows our strings to have the justified format. There are a number of other constants we could import that would allow us to right or left justify our text and do other fun things. Next is the platypus (which stands for Page Layout and Typography Using Scripts) module. It contains lots of modules, but probably the most important of them are the flowables, such as Paragraph. A flowable typically has the following abilities: wrap, draw and sometimes split. They are used to make writing paragraphs, tables and other constructs over multiple pages easier to do.

The SimpleDocTemplate class allows us to set up margins, page size, filename and a bunch of other settings for our document all in one place. A Spacer is good for adding a line of blank space, like a paragraph break. The Image class utilizes the Python Image Library to allow easy insertion and manipulation of images in your PDF.

The getSampleStyleSheet gets a set of default styles that we can use in our PDF. ParagraphStyle is used to set our paragraph’s text alignment in this example, but it can do much more than that (see page 67 of the user guide). Finally, the inch is a unit of measurement to help in positioning items on your PDF. You can see this in action where we position the logo: Image(logo, 2*inch, 2*inch). This means that the logo will be two inches from the top and two inches from the left.

I don’t recall the reason why Reportlab’s examples use a Story list, but that’s how we’ll do it here as well. Basically you create a line of text, a table, and image or whatever and append it to the Story list. You’ll see that throughout the entire example. The first time we use it is when we add the image. Before we look at the next instance, we’ll need to look at how we add a style to our styles object:

styles.add(ParagraphStyle(name='Justify', alignment=TA_JUSTIFY))

The reason this is important is because you can use the style list to apply various paragraph alignment settings (and more) to text in your document. In the code above, we create a ParagraphStyle called “Justify”. All it does is justify our text. You’ll see an example of this later in the text. For now, let’s look at a quick example:

ptext = '<font size=12>%s</font>' % formatted_time
Story.append(Paragraph(ptext, styles["Normal"]))

For our first line of text, we use the Paragraph class. As you can see, the Paragraph class accepts some HTML-like tags. In this instance, we set the font’s point size to 12 and use the normal style (which is left aligned, among other things). The rest of the example is pretty much the same, just with Spacers thrown in here and there. At the end, we call doc.build to create the document.

Wrapping Up

Now you know the basics for creating PDFs in Python using Reportlab. We didn’t even scratch the surface of what all you can do with Reportlab though. Some examples include tables, graphs, paginating, color overprinting, hyperlinks, graphics and much more. I highly recommend that you download the module along with its user guide and give it a try!

Further Reading

• Reportlab Home Page
• Generating Reports with Charts
• A series on Reportlab

I read chapters 1-6 and then skimmed 7-10. The author writes in an engaging manner and the chapters are broken up into sections, which makes it easy to pick up, do a section, and put it back down without losing your place. The primary reason that I was slow to review this book is that it has lots of code examples and it takes quite a while to re-type them all. I hate technical books that are riddled with broken code, so I wanted to make sure that this book’s code and tests worked. If I review a book with lots of code in the future, I will insist on lots of time or an e-book copy so I can just copy and paste the code.

Anyway, the first couple of chapters went by with only minor errors in the text itself. The content was pretty good, but the editors missed simple stuff where the author used “white” instead of “write”. There are silly mistakes like this in most chapters. The real problems don’t happen until chapter 3, which is about creating unit tests with doctest. On page 45, there’s a code example that includes the following line:

self.integrated_error +q= err * delta

Since the author recommends using Python 2.6, I thought that “+q=” might be some kind of new format that I was unaware of. But it’s just a typo. On page 48-50, he has a revised test from earlier in the chapter. The text clearly states that all revisions will be clearly marked. They are not and I was unable to find all the revisions to make the new version work. I didn’t want to re-type the entire thing in again, so I skipped it and decided to download the author’s code bundle from the publisher’s website.

Here is where things really went downhill for me. After getting the code, I noticed that the files and folders were not arranged by chapter, but by some other method. This made it very difficult to find what I was looking for. I eventually did find a chapters sub-folder in the “tests” folder (I think). My plan was to do a diff on that code versus mine. When I opened the book code though, I noticed that the author had included a bunch of mock tests in it. He doesn’t cover mock until chapter 4. I considered stopping here and just telling everyone I knew to avoid this book, but since I got it for free, I decided to soldier on.

Chapter 4 is on the Python Mocker package by Labix. This chapter was quite good and I think I learned a lot from it. The only downer was that the author mentioned that you could use easy_install to install this module and that by so doing, Nose would be ready to run. That was just plain dumb. Other than that, I thought this was a good chapter.

Chapter 5 introduced the reader to Python’s unittest library. I don’t recall if I tested all the code in this chapter or not, but I didn’t note anything that was wrong. I thought this was a good introduction to unittest, especially for a beginner.

For chapter 6, the topic is changed to Nose. As you may have noticed from my descriptions so far, the author is quite gradual in how he went through the topics. He started with doctests, moved to mock, then unittests and then Nose, which is kind of a test runner and enhancer. I had weird issues with Nose when I tried to easy_install it. For some reason, I ended up with the 0.10.1 version which didn’t work with all the commands in this book. Once I got the current version, everything worked better. I should note that I was unable to get the example on page 112 to pass nosetests. I have no idea what the problem is, although it has to do with the Python Mocker module. It may be that I mistyped something, but I couldn’t figure it out.

The author covers Nose’s configuration file briefly and goes over a few command line flags for nosetests. He also covers fixtures and how to use them to enhance your tests. Finally he shows how to use Nose’s pattern matching abilities to run tests that match a certain naming convention. Pretty cool stuff!

I started to skim in earnest after this chapter though. In seven, he does a step-by-step walk-through depicting how to test and create a personal scheduling program. I look forward to reading this section and seeing how complex or simple this is. There is certainly code aplenty in this section and lots of tests (or he may just be re-printing some of the examples in smaller parts for commentary). I have no idea if any of it is functional though.

In chapter 8, the book moves on to Web Testing with Twill. I thought this was an interesting choice since Twill’s website says that it hasn’t been updated in over 3 years. I tested a few of the examples in this chapter and they worked as advertised. Much of this section is made up of explanations of Twill commands though. The last section purportedly shows how to integrate Twill tests with unittest tests. I didn’t do that part though.

Chapter 9 talks about Integration and System testing. I thought the idea of drawing concentric circles in a diagram to figure out how to create integrated units for testing was a good concept. That will probably appeal to the readers who like visuals. Alas, I didn’t really read anything more than the first couple of pages, but it looks like he uses his schedule planner example here as well.

The final chapter entitled “Other Testing Tools and Techniques”. I think this chapter looks fairly interesting, but didn’t get a chance to read it. Looking at the text now, it would seem to briefly cover the following: coverage.py, version control hooks (Bazaar, Mercurial, Darcs, Subversion), and buildbot.

There is also an appendix with Pop Quiz answers.

Overall, I think the chapters that I read had a lot of good information and that is was very well organized. Unfortunately, the good was pretty badly marred by minor grammatical or sentence structure issues and the occasionally larger issue of broken code/tests. If it happens once, then I expect that there probably other code or tests that are broken as well. If this is the case, then I recommend buying it used or wait for a Packt sale of some sort. On the other hand, if the book is pristine after chapter 6…well, I guess that really doesn’t matter since that would mean that over half the book had problems.

Okay. Here’s a better recommendation: Find a Borders or Barnes & Nobles near you that has the book and free wi-fi. Go there, find the book, and read it and mess around with the examples BEFORE you buy it.

Rating Scale: 1 (low) – 5 (high)

Code rating = 3
Writing = 4
Organization = 5

Average Score = 4 (take a point or two off if broken code annoys you)

When I first started searching on this topic, I tried such search terms as “python peak commit value” and variations thereof. That got me nowhere, so I replaced “oython” with “wmi” and found the Win32_PerfFormattedData_PerfOS_Memory Class on MSDN. I thought this was it, but it only gave me the Commit Charge Limit and the Total Commit Charge. Here’s how I got those values using Tim Golden’s WMI module:

import wmi
 
c = wmi.WMI()
 
for item in c.Win32_PerfFormattedData_PerfOS_Memory():
    commitChargeLimit = int(item.CommitLimit) / 1024
 
for item in c.Win32_PerfFormattedData_PerfOS_Memory():
    commitChargeTotal = int(item.CommittedBytes) / 1024
 
print "Commit Charge Limit: ", commitChargeLimit
print "Commit Charge Total: ", commitChargeTotal

This is neat stuff and shows how easy it is to take the documentation at MSDN and translate it into something usable in Python. Unfortunately, it just didn’t give me the information I needed. My next stop was the PyWin32 mailing list where Mark Hammond informed me of the win32pdh and win32pdhutil modules. These expose performance counters, but I couldn’t find a way to use it to get this information either. Fortunately, I found an old post on the sysinternals forum that gave me a clue. Here is what it said:

The only way I’m aware of that one can get this detail is from the uMmPeakCommitLimit member of the SYSTEM_PERFORMANCE_INFORMATION structure one passes to NtQuerySystemInformation when calling it with the SystemPerformanceInformation type.

I asked Mr. Hammond if that meant that I would need to use ctypes since the NtQuerySystemInformation class isn’t exposed by PyWin32 and he said “probably”. The ctypes module is pretty low-level and not something I’ve used except when I’ve copied a script from ActiveState. It’s a pretty handy module though and was added to the standard library in version 2.5. From what I can tell, it was created by Thomas Heller.

Anyway, ctypes has its own mailing list, so I decided to try there. I received two replies, one of which was from the man himself (Heller). He gave me a script that didn’t appear to work at first, but after a little back and forth with him, he got me straightened out. Here’s the result:

from ctypes import *
 
SystemBasicInformation = 0
SystemPerformanceInformation = 2
 
class SYSTEM_BASIC_INFORMATION(Structure):
    _fields_ = [("Reserved1", c_long * 10),
                ("NumberOfProcessors", c_byte),
                ("bUnknown2", c_byte),
                ("bUnknown3", c_short)
                ]
 
class SYSTEM_PERFORMANCE_INFORMATION(Structure):
    _fields_ = [("IdleTime", c_int64),
                ("ReadTransferCount", c_int64),
                ("WriteTransferCount", c_int64),
                ("OtherTransferCount", c_int64),
                ("ReadOperationCount", c_ulong),
                ("WriteOperationCount", c_ulong),
                ("OtherOperationCount", c_ulong),
                ("AvailablePages", c_ulong),
                ("TotalCommittedPages", c_ulong),
                ("TotalCommitLimit", c_ulong),
                ("PeakCommitment", c_ulong),
                ("PageFaults", c_ulong),
                ("WriteCopyFaults", c_ulong),
                ("TransitionFaults", c_ulong),
                ("Reserved1", c_ulong),
                ("DemandZeroFaults", c_ulong),
                ("PagesRead", c_ulong),
                ("PageReadIos", c_ulong),
                ("Reserved2", c_ulong * 2),
                ("PagefilePagesWritten", c_ulong),
                ("PagefilePageWriteIos", c_ulong),
                ("MappedFilePagesWritten", c_ulong),
                ("MappedFilePageWriteIos", c_ulong),
                ("PagedPoolUsage", c_ulong),
                ("NonPagedPoolUsage", c_ulong),
                ("PagedPoolAllocs", c_ulong),
                ("PagedPoolFrees", c_ulong),
                ("NonPagedPoolAllocs", c_ulong),
                ("NonPagedPoolFrees", c_ulong),
                ("TotalFreeSystemPtes", c_ulong),
                ("SystemCodePage", c_ulong),
                ("TotalSystemDriverPages", c_ulong),
                ("TotalSystemCodePages", c_ulong),
                ("SmallNonPagedLookasideListAllocateHits", c_ulong),
                ("SmallPagedLookasideListAllocateHits", c_ulong),
                ("Reserved3", c_ulong),
                ("MmSystemCachePage", c_ulong),
                ("PagedPoolPage", c_ulong),
                ("SystemDriverPage", c_ulong),
                ("FastReadNoWait", c_ulong),
                ("FastReadWait", c_ulong),
                ("FastReadResourceMiss", c_ulong),
                ("FastReadNotPossible", c_ulong),
                ("FastMdlReadNoWait", c_ulong),
                ("FastMdlReadWait", c_ulong),
                ("FastMdlReadResourceMiss", c_ulong),
                ("FastMdlReadNotPossible", c_ulong),
                ("MapDataNoWait", c_ulong),
                ("MapDataWait", c_ulong),
                ("MapDataNoWaitMiss", c_ulong),
                ("MapDataWaitMiss", c_ulong),
                ("PinMappedDataCount", c_ulong),
                ("PinReadNoWait", c_ulong),
                ("PinReadWait", c_ulong),
                ("PinReadNoWaitMiss", c_ulong),
                ("PinReadWaitMiss", c_ulong),
                ("CopyReadNoWait", c_ulong),
                ("CopyReadWait", c_ulong),
                ("CopyReadNoWaitMiss", c_ulong),
                ("CopyReadWaitMiss", c_ulong),
                ("MdlReadNoWait", c_ulong),
                ("MdlReadWait", c_ulong),
                ("MdlReadNoWaitMiss", c_ulong),
                ("MdlReadWaitMiss", c_ulong),
                ("ReadAheadIos", c_ulong),
                ("LazyWriteIos", c_ulong),
                ("LazyWritePages", c_ulong),
                ("DataFlushes", c_ulong),
                ("DataPages", c_ulong),
                ("ContextSwitches", c_ulong),
                ("FirstLevelTbFills", c_ulong),
                ("SecondLevelTbFills", c_ulong),
                ("SystemCalls", c_ulong)]
 
sbi = SYSTEM_BASIC_INFORMATION()
retlen = c_ulong()
 
res = windll.ntdll.NtQuerySystemInformation(SystemBasicInformation,
                                            byref(sbi),
                                            sizeof(sbi),
                                            byref(retlen))
print res, retlen
print sbi.NumberOfProcessors
 
 
spi = SYSTEM_PERFORMANCE_INFORMATION()
retlen = c_ulong()
 
res = windll.ntdll.NtQuerySystemInformation(SystemPerformanceInformation,
                                            byref(spi),
                                            sizeof(spi),
                                            byref(retlen))
print res, retlen
print "Peak commit: ",
print spi.PeakCommitment * 4096 / 1024

I don’t really understand everything that’s going on here, but I’m glad it works. Well, I should say that it works on Windows XP Professional, 32-bit with Python 2.5. I tried it on Windows 7 64-bit as well and while the script ran, it returned “0L”. I’m guessing that 64-bit operating systems need a slightly different script, but since all our workstations currently use 32-bit, it doesn’t really matter at this point. Once again, the Python community came through for me and showed me just how amazing they are!

After some research, I discovered that most well-behaved software will store various pieces of information about themselves in the Windows Registry. Specifically, they usually store this information in the following location: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall

It should be noted that not all programs that you install will put that information in the Registry. We have vendors who don’t use the Registry at all, for example. Also, nefarious programs like malware probably won’t put anything there either. However, well over 90% do so this is a good way to get the information. To get more, you’d probably need to do some directory walking with Python’s os module using it’s “walk” methods and look for mismatches from that compared to what’s in the Registry or maybe from some stored image that you’ve kept from a virgin base machine.

Anyway, enough talk. Let’s take a look at the code! Note: if you’d like to follow along then you’ll need to download and install Tim Golden’s WMI module.

import StringIO
import traceback
import wmi
from _winreg import (HKEY_LOCAL_MACHINE, KEY_ALL_ACCESS,
                     OpenKey, EnumValue, QueryValueEx)
 
softFile = open('softLog.log', 'w')
errorLog = open('errors.log', 'w')
 
r = wmi.Registry ()
result, names = r.EnumKey (hDefKey=HKEY_LOCAL_MACHINE, sSubKeyName=r"Software\Microsoft\Windows\CurrentVersion\Uninstall")
 
softFile.write('These subkeys are found under "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall"\n\n')
errorLog.write("Errors\n\n")
separator = "*" * 80
keyPath = r"Software\Microsoft\Windows\CurrentVersion\Uninstall"
 
for subkey in names:
    try:
        softFile.write(separator + '\n\n')
        path = keyPath + "\\" + subkey
        key = OpenKey(HKEY_LOCAL_MACHINE, path, 0, KEY_ALL_ACCESS)
        try:
            temp = QueryValueEx(key, 'DisplayName')
            display = str(temp[0])
            softFile.write('Display Name: ' + display + '\nRegkey: ' + subkey + '\n')
        except:
            softFile.write('Regkey: ' + subkey + '\n')
 
    except:
        fp = StringIO.StringIO()
        traceback.print_exc(file=fp)
        errorMessage = fp.getvalue()
        error = 'Error for ' + key + '. Message follows:\n' + errorMessage
        errorLog.write(error)
        errorLog.write("\n\n")
 
softFile.close()
errorLog.close()

This is a pretty short snippet, but there’s a lot going on here. Let’s unpack it. First we import the modules we need and then open a couple of files: softFile will store all the software our script finds in “softLog.log” whereas our errorLog variable will store any errors we encounter in “errors.log”. Next we use WMI to enumerate over the subkeys in the “Uninstall” key. After that, we write a some title info to each log file to make them easier to read.

The last important piece occurs in the loop structure. Here we loop over the results returned from our WMI call. In our loop, we try to pull out two pieces of information: the Display Name of the software and the key that it’s associated with. There is lots of other information to be had, but there doesn’t seem to be any standards that are adhered to, so I didn’t grab any of that. You would need more complex error handling to extract it nicely (or maybe use generators some how). Anyway, if either of the pieces that we try to pull out fails, we catch the error and keep going. The nested exception handing catches the error related to getting the display name whereas the outer exception handler catches errors related to accessing the Registry. We should probably make these exceptions explicit (for example, the latter should be WindowsError, I think), but this is just a quick and dirty script. Feel free to extend it as much as you deem necessary.

If we encounter an error in either location, we log something. In the nested case, we just log the Regkey’s name to “softLog.log”, whereas in the outer case, we just log an error to “errors.log”. At the end, we clean up by closing the files.

Here’s a partial sample of what I get when I run this script on my Windows XP machine:


These subkeys are found under "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall"

Display Name: Aspell English Dictionary-0.50-2
Regkey: Aspell English Dictionary_is1
********************************************************************************


Now you know how to extract most of the software installed on your Windows box. I’ve tested this primarily on Windows XP with Python 2.5, but it should work on Windows Vista and 7 too. Windows 7 and Vista usually forces the default user to run with lower privileges that XP, so you may be required to run this script as Administrator or impersonate the Administrator. Have fun!

The first evening I was at PyCon, I was approached by some guy who wanted to know if I would do some data entry. He had a bunch of tutorial surveys that needed to be entered for Greg Lindstrom, founder (I think) of Elegant Stitches (AKA: WearPython). So I ended up doing some of that once I actually found a location where the PyCon wireless worked.

My next act of good will occurred Friday morning. I had just found a place a sit near an access point when this fellow came up to me and asked if I could help put the power strips under the tables. This was in the main auditorium. I ended up doing about half the room. Sometime during that, another fellow started helping me. The objective was to plug them all together from the front to the back, usually in two series. The biggest drawback to this method is that if anyone in the back bumped their power strip’s switch, then all the people who were feeding off that one would lose power. I never heard if this was an issue or not.

My final volunteering activity was being a Session Chair. I actually talked about that in another post, so I won’t repeat myself here. I’ll just say that it was a mostly good experience other than some minor audio issues and some butterflies.

I was kind of hoping to get an awesome staff tee, but the main staff tees were lame. They’re just black with some white lettering and the PyCon logo. If you were paying attention at the conference, then you’d know that the only differences between the staff and the conference tees were slightly different verbiage and the fact that one was black and the other blue. Oh well. I do like the PyCon logo, but it would have been cooler if they had a large logo on the back too or something.

Next year, I encourage you all to get out there and volunteer to make PyCon 2011 even better!

Oddly enough, my other method happened to use something of Tim Golden’s; namely, his winshell module. Check it out below:

import os
import winshell
 
program_files = winshell.programs()
winshell.CreateShortcut (
               Path=os.path.join (program_files, 'My Shortcut.lnk'),
               Target=r'C:\Program Files\SomeCoolProgram\prog.exe')

Let’s unpack this so you know what’s going on. First, we use winshell to find the user’s “Programs” folder, which is a sub-folder of the user’s “Startup” folder. Then we use winshell’s CreateShortcut method to actually create the shortcut. If you look at the CreateShortcut’s docstring, you’ll discover that it can also accept the following keyword arguments: Arguments, StartIn, Icon, and Description.

Oddly enough, this wasn’t the method that Golden was suggesting in his comment. He had another idea that is quite a bit more complicated. Let’s take a quick look:

import os, sys
import pythoncom
from win32com.shell import shell, shellcon
 
shortcut = pythoncom.CoCreateInstance (
  shell.CLSID_ShellLink,
  None,
  pythoncom.CLSCTX_INPROC_SERVER,
  shell.IID_IShellLink
)
program_location = r'C:\Program Files\SomeCoolProgram\prog.exe'
shortcut.SetPath (program_location)
shortcut.SetDescription ("My Program Does Something Really Cool!")
shortcut.SetIconLocation (program_location, 0)
 
desktop_path = shell.SHGetFolderPath (0, shellcon.CSIDL_DESKTOP, 0, 0)
persist_file = shortcut.QueryInterface (pythoncom.IID_IPersistFile)
persist_file.Save (os.path.join (desktop_path, "My Shortcut.lnk"), 0)

In my opinion, this is getting a little too low-level for my taste. However, it is also really cool that you can do it this way. If you look at Tim Golden’s linked page, you’ll see that this example is practically just a copy and paste job. I think winshell’s desktop method does the same thing as “shell.SHGetFolderPath (0, shellcon.CSIDL_DESKTOP, 0, 0)” and it’s easier to read. Anyway, the code above does the same thing that the previous code does, only it puts the shortcut on the user’s desktop. I don’t really understand what Golden is doing in the “pythoncom.CoCreateInstance” part other than creating an object that we can use to create our shortcut.

Also note that Tim Golden talks about creating a URL shortcut using a method that is quite similar to the one detailed above. You can go to his website and learn all the juicy details.

Anyway, I felt that to be complete, I’d better write up these other two methods of creating shortcuts in Windows. Hopefully you found this interesting and maybe even educational.

The first Plenary of the morning was given by Frank Wierzbicki of Sauce Labs and he talked about the “State of Jython”, the Java implementation of Python. It turns out that version 2.5.1 has really good compatibility with the normal Python implementation such that Jython passes almost all of CPython’s test suite. Jython also work with most Java libraries and applications, so you can get the best of both worlds.

Wierzbicki went on to say that any pure Python code should work in Jython. He gave examples of SqlAlchemy, Django, Pylons, pip, web2py and distribute as working in Jython. The current plan for Jython is to shoot for a 2.6 release this summer to get Jython to Python’s 2.6 status and then, depending on how far along Python developers are in porting their applications to Python 3, he would like to have Jython start porting to 3.x as well.

He put a call out for assistance on the Jython project as they no longer have sponsors. He then wrapped it up with a demo using the Sikuli script by Joseph Chang from MIT that used Jython to play Bejeweled. Weird, but cool!

The second plenary was on the “State of Unladen Swallow” and given by Collin Winter who works for Google. He didn’t use slides since he said that we could refer to a talk he’d given on Saturday if we needed visuals. Winter told us how their interpreter was faster than Jython and PyPy, but that it could be optimized up the wazoo. He announced that Guido had approved the merging of Unladen Swallow into the Python 3.x code base, hopefully in time for 3.3. Winter said that he hoped that by merging the code, they would gain many more developers who could get the optimizing process up to warp speed and make a really fast interpreter. Finally, Winter noted that Unladen Swallow has 100% compatibility with all current Python code and gave the example that Unladen Swallow made Django run 20% faster.

The final plenary was given by the entrepreneur Antonio Rodriguez, founder of tabblo (which he subsequently sold to HP). Here are a few of my notes from the talk:

• success = [e.hack() for e in employees]
• Every machine can run the full stack. Anyone can check out the full tree and build the full product. Anyone can make a change to any part of the source tree. Everyone has commit bits. Anyone can push to production.
• 98% of companies start with around 10 people
• Business vs. tech is a false dichotomy
• The lean startup should be the emaciated startup

The challenges that he saw for Python were getting people to commit to porting to 3.x so the split wouldn’t continue, need more batteries in the standard library and the packaging problem. I highly recommend waiting for the video and watching it as I am not explaining his talk very well and I thought he gave the best talk that I attended.

• Please Pirate – This one was given over half an hour BEFORE lightning talks were scheduled. I don’t know why. His talk’s website is www.pleasepirate.com. His premise was that people should encourage others to pirate their intellectual property. It was pretty confusing, actually. He doesn’t think Creative Commons goes far enough either.

• You can write stored procedures in postgres – This was like a 60 second advertisement.

• PyAr – Natalia from the Argentina Python Users group spoke on how their group started and its mission / vision. It has 650+ members with a mailing list of 11000+ messages per month. She also talked about what they do as a group, such as PyCamps and sprints (cocos2d, lalita, CDPedia)

• Python Spring Cleanup – go home, figure out how to contribute to python, demo your stuff at a Python Users Group, get others to do it too

• You got your Cython in my NumPy – by D. Huggins – Went through a bunch of iterations of k-means code to show how Cython could make Python code much faster. He messed up at the end, so we never got to see how fast it really was.

• PiCloud – inspiration was facebook photo-tagging assistant but it turned into some kind of cloud-computing program. I didn’t really follow this very well, but they seem to have created a “cloud” module/package that allows you to utilize Amazon’s resources (EC2?) to do calculations.

• Mox – Mobile web in Django, presented by Tim Fernando from Oxford, UK – Molly is a soon-to-be open source project that focuses on providing web content to mobile devices. Example (I think) is m.ox.ac.uk. It also does maps and it’s RESTful

• CCP Games guy – custom stackless or socket api (accent is hard to understand), used cherrypy’s thread test to compare against his program to show that his version was super fast. I couldn’t read the screen, so I don’t know if he proved anything or not.

For example, I wanted to go to the Python Authors BoF (BoF = Birds of a Feather). When I went down there, the outside board said it was in so-and-so and the inside board was blank. I went looking for this room, but found other people instead (I think they were the django folk). I don’t know where the authors thing was or if it even happened.

My wxPython BoF fared no better. I had put down my time slot on both boards in hopes of mitigating the confusion, but there was some huge group in the room I had reserved anyway. They left about 5-10 minutes after my BoF was supposed to start, which I think caused us to lose participants. We only had 6 people show up whereas last year it was closer to triple that amount.

All in all though, I think the wxPython BoF was alright because I got to meet the two major developers behind Dabo, Ed Leafe and Paul McNett. And Stani showed up too, so I was able to rub shoulders with a few of the cool people of the wxPython niche. We discussed various projects we were working on and helped a wxPython newbie.

Another annoyance was that there never seemed to be any cards handy to fill out to post on the board(s)!. If I’m able to attend PyCon next year, I hope that this area of the conference is shown more love.

She started “Python Newbie Night” in Toronto, Canada. It was an informal, peer-taught class which often put code up on the wall with a projector. They would work through the Python book, “How to Think Like a Computer Scientist” which has chapter exercises (the book is online for free at http://thinkpython.com). She was in a hackerspace (her local one was hacklab.co) and seemed to recommend them. She gave a list of venues for teaching programming such as Community centres, churches, retirement homes, schools, jails and more. She also mentioned that the University of Toronto has switched to teaching Python from Java (I think).

She spoke on what worked for these classes and what didn’t work so well. For the most part, the talk was just general purpose tips for teaching Python. I do most of the stuff that she talks about for Pyowa (local python users group) and completely agree that doing it alone sucks. I also agree that teaching others about Python can be very rewarding. I thought this was a nice informal talk that would be informative to people who have never done this before. If you plan to start a user’s group, watching her talk or reading her slides would be a step in the right direction.