Comment 1 for bug 518732

Hey Mark, thanks for your work on this one.
I didn't test it but I read the code, and it looks correct to me.

Supporting file-like objects sounds neat, but I was wondering what's the most common use-case, and it occurred to me that in general image manipulation libraries rather give you access to a data buffer than to a file-like interface. See for example PIL.Image, and its tostring() method (http://www.pythonware.com/library/pil/handbook/image.htm#Image.tostring). Anyway, I think this use-case ought to be considered, at least as seriously as supporting file-like objects.

If we are to support different "constructors" for ImageMetadata, I would rather go for static methods than a polymorphic constructor (which implies magic code and is harder to document), e.g.:

  ImageMetadata.open(filename_or_file)
  ImageMetadata.from_buffer(data)

If .open() (or .__init__()) is called with a file-like object, the file can be .read() from the python code and the data passed directly to .from_buffer(), which avoids the need for a tricky data stream constructor in C++.

I'm open to comments, critics and suggestions. Let's agree on the API before implementing it.