On Thu, 02 Feb 2006 17:00:26 -0800, Blair P. Houghton wrote: > Image would be a superclass to JPGImage, BMPImage, PNGImage, etc... > > But which to use could only be determined AFTER opening the file, > because "file.jpg" doesn't have type JPG, it has type string and > semantic value "maybe a jpeg file or maybe something misnamed as a jpeg > file".
Absolutely. > So Image.open(filename) seems right as a factory function that opens > the file, figures out what it really is, constructs the appropriate > subclass object (likely by passing a string to the constructor, e.g., > JPGImage(filename)), and returns the object via the superclass type. > The caller can then either check a flag in the superclass to see what > type the subclass is, or just assume it's the right type of image for > the filename extension (or does Python have RTTI? I don't recall if > I've seen it, yet...). RTTI = Run Time Type Information, yes? Objects in Python are strongly typed, if that's what you mean. So if each image kind (jpeg, tiff, png, etc.) is a subclass, then you can easily use introspection to find out which subclass it is. > Though if the filename doesn't match the content, someone should raise > an exception... That depends on whether you believe DOS style filename extensions are significant, or that they are a poor substitute for real metadata. If you come from Windows land, you might thing the file extension is the file type. If you come from Linux land, you might think that file extensions are just a label stuck on the file name as a convenience for the user. If you come from Macintosh land, especially pre-OS X, you probably think that file extensions are at best a useful redundancy and at worst an abomination. >From a UI perspective, an application should never refuse to handle a file because of a mismatch between the file type contents, the file type metadata (if any), and the file extension, with one important proviso as follows. In general, if your application handles (say) both JPEGs and GIFs, and the user tries to open a JPEG named foo.gif, then the correct action is to advise the user that the file is actually a JPEG, and give them the opportunity to open the file anyway. Whether that is best handed internally by making Image.read() raise an exception or not is a question for the class designer. The proviso is, if there are potential security implications of that mismatch (e.g. an executable file masquerading as a .text file), and the target audience is technically naive, then I believe it may be appropriate for the application to refuse to handle the file. Don't let the user shoot themselves in the foot if they aren't technically sophisticated enough to realise they are shooting themselves in the foot. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list