On 2010-04-26, Matti Airas wrote:
> Mark,
>
> I quite like the idea of putting all QtCore "globals" to a separate
> namespace. However, maybe we could clean it up a bit while at it?
Yes, of course! The way I see it is that the aim is to make PySide as
Pythonic & good as possible, while at the same time making it as
compatible and easy to switch to from PyQt as possible with the former
being more important than the latter.
> Apparently the PyQt4.QtCore module functions fall to three different
> categories:
>
> pyqt.* for the Python-specific APIs
> q.* for assorted utility functions in QtGlobal.h in C++
> rest for QTextStream's utility functions
>
> So, my proposal is we deal with these three categories separately (maybe
> even separate PSEPs?).
Sure. Who is volunteering?
> The q.* utility functions could maybe even stay in QtCore module
> namespace? They're probably not interfering with anything and importing
> them in QtCore would be consistent with native Qt's behaviour.
Sounds reasonable.
> As for the pyqt.*, for QtCore.pyqtSignal (not even mentioned in the
> QtCore reference O_o) and QtCore.pyqtSlot we already made a decision in
> PSEP 100 to rename them to QtCore.signal and QtCore.slot. Of course,
> nothing prevents us from amending or changing that decision... Would it
> work if all of these would be moved to the Qt module and the pyqt prefix
> would be removed?
I'd prefer them to be Qt.signal and Qt.slot. People could still use the
bare names by doing: from Qt import signal, slot, but for those who
prefer to avoid from-style imports I think Qt.signal and Qt.slot are
nicer.
> As for the QTextStream's utility functions, IMO they could be moved to a
> module of their own. Maybe PySide.Stream?
I think there's confusion here between QTextStream and QDataStream. I
personally haven't looked at QTextStream since I can't see any reason to
use it compared with Python's own facilities. However, QDataStream is a
different matter since that makes it possible to read/write formats that
can be read/written by C++/Qt programs, so getting it right is
important.
> The Compatibility module you suggested could then import all of these in
> the right places.
Exactly.
> This is already off the QtCore cleanup topic but I also really dislike
> the whole C++ -like stream syntax (or at least having it imported to
> Python). I wonder would it be a too big and unnecessary deviation
> providing no functional advantage but maybe we could offer at least an
> alternative method-call syntax, e.g.:
>
> stream.write(movie.title).write(movie.acquired).write(movie.notes)
>
> instead of
>
> stream << movie.title << movie.acquired << movie.notes ?
The C++ << syntax is wrong for Python. No experienced Python programmer
is going to expect it. I think that it could be supported if the
Compatibility module is imported but not otherwise.
For QTextStream writing should be supported with a QTextStream.write()
method that takes a single string (like Python's library modules' write
methods):
stream.write("{} {} {}".format(movie.title,
movie.acquired.toString(Qt::ISODate), movie.notes))
(Of course for Python 2, you'd use the % operator, but the
QTextStream.write() method would be the same.)
This also means that we don't have to support (except perhaps in the
Compatibility module) the stream manipulators ("bin", "oct", "showbase",
"endl", etc.)
For QDataStream things are more difficult because the data is stored in
binary format, so, for example, exact sizes of numbers is needed. Hence,
PyQt has:
QDataStream.writeInt16()
QDataStream.writeUInt16()
...etc...
Unfortunately PyQt also has
QDataStream.writeString()
QDataStream.readString()
which only writes/reads a QByteArray!
If we want compatibility, we should support the PyQt methods as is.
However, we could add:
QDataStream.writeStr() # writes a Python 2 unicode or Python 3 str
# as a QString
QDataStream.readStr() # reads a QString and returns a Python 2
# unicode or Python 3 str
--
Mark Summerfield, Qtrac Ltd, www.qtrac.eu
C++, Python, Qt, PyQt - training and consultancy
"Programming in Python 3 (Second Edition)" - ISBN 0321680561
_______________________________________________
PySide mailing list
[email protected]
http://lists.openbossa.org/listinfo/pyside
