2009/10/22 Anderson Lizardo <[email protected]>: > 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). Yes, there is "bool QFile::open(FILE* fh, OpenMode mode)" (this one is not exported in the current PySide), and the file handler could be obtained from a Python file object with the "fileno()" method. AFAIK we can't do that the other way around. In any case with two different file objects holding the same file handler it would be a problem when the destructor of the first object to die sets the handler free. I would prefer to use only one file object.
>> - 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). I'm be more inclined to merge the QFile instantiation with the open method, but this method is virtual (and inherited from QIODevice) and is possible that someone relies on this. > 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). Great idea. :) >>> 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. Exactly. -- Marcelo Lira dos Santos INdT - Instituto Nokia de Tecnologia _______________________________________________ PySide mailing list [email protected] http://lists.openbossa.org/listinfo/pyside
