This was explicitely merged in to "fix a bug". I think your pull needs to override this behavior, since the previous addition of the close() call actually broke the default behavior of using a pisaTempfile (that raises an AttributeError right now).

Merging this in.

This commit led to my application creating blank files (invoices as orders come in). I was able to get it working by manually closing the file (calling dest.close()). Perhaps I am doing it the wrong way, but even something this simple is not working:

from xhtml2pdf import pisa
pdf = pisa.CreatePDF("Hello World", file("test.pdf", "wb"))

That will work if called from the command line because Python finishes executing and it will close out the file, but if the PDF is generated from something like Django, you'll end up with an unclosed file that can't be used (my application was emailing a PDF invoice to sales people). I had to update the code to be:

from xhtml2pdf import pisa
pdf = pisa.CreatePDF("Hello World", file("test.pdf", "wb"))
pdf.dest.close()

There has to be a better way to handle this.

That's precisely the thing to do for how it is implemented now.

The only thing I can think of is to add an parameter:

pdf = pisa.CreatePDF("Hello World", file("test.pdf", "wb"), close=True)

and if you are using a StringIO:

file_obj = StringIO.StringIO()
pdf = pisa.CreatePDF("Hello World", file_obj, close=False)

If the default for close would be True it would stay backwards compatible. But there definitely needs to be a way to use StringIO objects, so it's possible to do stuff in RAM without touching the filesystem.

Why not just check if it's a file object and close it if so?

Because of "DuckTyping" it is hard to tell what the thing that gets passed in really is. StringIO and File both have a file like signature. What if you use some alternative implementation of something like StringIO. That could never be detected in a reliable way. So I guess we could make it work automatically for StringIO, but the optional parameter would still have to exist for other cases.

I was more thinking checking for if it was the file class and if so closing it, but you're right in that there are enough file like objects that explicitly checking is a bad idea. I'd be happy with the addition of a close argument (defaulting to true) then. It would make the examples function again at least.