Why not take ownership of the file object, instead of requiring users to manage lifetimes?
-- Devin On Wed, Nov 25, 2015 at 12:52 PM, Chris Lalancette <clalance...@gmail.com> wrote: > Hello, > I'm currently developing a library called pyiso ( > https://github.com/clalancette/pyiso), used for manipulating ISO disk > images. I'm pretty far along with it, but there is one part of the API > that I really don't like. > Typical usage of the library is something like: > > import pyiso > > p = pyiso.PyIso() // create the object > f = open('/path/to/original.iso', 'r') > p.open(f) // parse all of the metadata from the input ISO > fp = open('/path/to/file/to/add/to/iso', 'r') > p.add_fp(fp) // add a new file to the ISO > out = open('/path/to/modified.iso', 'w') > p.write(out) // write out the modified ISO to another file > out.close() > fp.close() > f.close() > > This currently works OK. The problem ends up being the file descriptor > lifetimes. I want the user to be able to do multiple operations to the > ISO, and I also don't want to read the entire ISO (and new files) into > memory. That means that internal to the library, I take a reference to the > file object that the user passes in during open() and add_fp(). This is > fine, unless the user decides to close the file object before calling the > write method, at which point the write complains of I/O to a closed file. > This is especially problematic when it comes to using context managers, > since the user needs to leave the context open until they call write(). > I've thought of a couple ways to deal with this: > > 1. Make a copy of the file object internal to the library, using os.dup() > to copy the file descriptor. This is kind of nasty, especially since I > want to support other kinds of file objects (think StringIO). > 2. Just document the fact that the user needs to leave the file objects > open until they are done. This is simple, but not super user-friendly. > > I'm looking for any ideas of how to do this better, or something I missed. > Any input is appreciated! > > Thanks, > Chris Lalancette > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
