Brandon Craig Rhodes added the comment: Kristján, you are certainly correct that a single-argument that can be either a filename or a cert is inappropriate; we should not be peeking inside of strings to guess what they contain.
And I think you also have a good point about Pythonic-ness when it comes to polymorphism; routines that are sensitive to object type have been going more and more out of style for the past twenty years, and for good reason. But, having ceded those points, I still think string-or-file-like-object is the correct approach here, simply because it is the overwhelming approach of the Standard Library; everyone is used to it, and will already "know the ropes" of that approach; and it prevents noisying up the interface with redundant arguments. Were we doing this over again, we would simply not allow a filename at all, and let the user open the file if they needed to. But since a filename is allowed, it feels like the Official Standard Library Approach to also allow a file-like object. Some examples: zipfile.ZipFile: "Open a ZIP file, where file can be either a path to a file (a string) or a file-like object." http://docs.python.org/2/library/zipfile#zipfile.ZipFile binhex.hexbin: "Decode a binhex file input. input may be a filename or a file-like object supporting read() and close() methods." http://docs.python.org/release/2.7.5/library/binhex.html#binhex.hexbin xml.dom.minidom.parse: "filename_or_file may be either a file name, or a file-like object." http://docs.python.org/2/library/xml.dom.minidom.html#xml.dom.minidom.parse mailbox.Mailbox.add: "Parameter message may be a Message instance, an email.message.Message instance, a string, or a file-like object (which should be open in text mode)." http://docs.python.org/2/library/mailbox.html#mailbox.Mailbox.add pickletools.dis: "pickle can be a string or a file-like object." http://docs.python.org/2/library/pickletools.html#pickletools.dis I suggest that these precedents, along with others that I believe we could find with a more exhaustive search of the Standard Library, are sufficient to suggest that in this case the least-surprise approach is a single argument that's either a filename or file-like object. I would suggest reviewing quickly the code for the above examples and following their example for how to distinguish most cleanly between a filename and file-like object; I wonder if they call any common code to get the contents out, or each do it completely by themselves? :) Thanks again for wanting to add this to the SSL module, it will be a *great* addition that solves an important use case! ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue16487> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
