On Thu, Oct 22, 2009 at 4:52 AM, Matti Airas <[email protected]> wrote: > Also a couple notes as food for thought (I don't necessarily propose these > ideas but they could be discussed): > > - Would it be possible to use QFile and Python file object interchangeably?
That would be nice, although I'm not sure of the complexity of implementing it (for it to work, I suppose there should be a QFile method that takes a "raw" open file descriptor and use it). > - Is there any use for instantiated but unopened QFile objects? Couldn't we > open the file at the instantiation time? I think unopened QFile are useful at least from a "design" point of view, e.g., if you want to separate in your application the resource allocation (i.e. class instantiation) from the resource usage (i.e. opening/closing/reading files). Maybe on the same subject: would it be appropriate to add to the same PSEP a implementation for the with() protocol for QFile? See http://docs.python.org/reference/datamodel.html#context-managers for the details. It could allow something like: with QFile("/tmp/file.txt") as f: data = f.readAll() ... the with statement is available since python2.5 (but not enabled on it by default; needs the "from __future__ import with_statement"; on python2.6 and newer it is already default). >> The information contained in the exception could be gathered from >> QFile::error and QIODevice::errorString. >> Other candidates are QIODevice::read and QIODevice::write. > > Shouldn't the error information be included in the exception itself? I think Marcelo intended exactly this: the Python exception information would be get from these methods meaning having something like this on the generated binding: PyErr_SetString(..., QIODevice::errorString(...), ...); He can confirm this, though. Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil _______________________________________________ PySide mailing list [email protected] http://lists.openbossa.org/listinfo/pyside
