On 21.04.2010 17:13, ext Mark Summerfield wrote:
Looks fine to me.
But since only QtDBus needed this and you're going to use dbus-python,
couldn't we just defer this unless/until it is needed? Then we get a
nice clean no-QVariant API:-)
OK, this time the modifications are slightly bigger (including
reordering of paragraphs) so I cut and pasted the whole section below. I
cut a few corners and left the decision of retaining QVariant to the
implementation phase. I admit it's not the cleanest approach in the
world but if you're OK with this, it could save us some time and effort
juggling with the PSEPs in the future.
--8<----8<----8<----8<----8<----8<----8<----8<--
No QString and almost no QVariant
---------------------------------
The key difference between the APIs is that API 2 does not make QString
or (to some extent) QVariant available to programmers.
This means using Python's native string types for strings (e.g., unicode
for Python 2 and str for Python 3).
PyQt's approach to dealing with QVariants will be mimicked: any Python
objects are automatically converted to and from QVariants wherever
QVariants must be passed as arguments and when QVariants are returned.
By supporting automatic conversion to and from QVariants, any Python
object (including dicts, lists, and tuples) can be used wherever a
QVariant is expected, so most programmers most of the time won't have to
know or care about QVariant at all.
If the need arises during the implementation phase, the QVariant class
may be kept in the API so that programmers can pass a QVariant
explicitly if they need to. In this case, to support the creation of
QVariants a set of static functions named after the types in
QVariant.Type are implemented, e.g.::
QVariant.fromUInt(pythonObject) -> QVariant
QVariant.fromInt(pythonObject) -> QVariant
The benefit of API 2 in this regard is that programmers never have to
explicitly convert between QString and str, so programmers never get
caught out accidentally trying to use a QString method on a str or vice
versa. For the Qt APIs that accept or return QVariants, API 2 allows
programmers to pass any Python object and when a QVariant is returned
from Qt it is automatically converted to its original Python type (with
an invalid QVariant mapped to None).
For QString, API 2 goes beyond simply replacing QString with str (or
unicode on Python 2). In particular, API 2 also automatically converts
QChar and QStringRef to and from strs (or unicodes on Python 2). It also
converts QStringList to and from a Python list of strs (list of unicodes
on Python 2). (PyQt4's API 2 does not implement QLatin1Char,
QLatin1String, or QStringMatcher.)
Native C++/Qt QStrings are mutable, so PyQt4's API 2 has changed the
signatures of some of the affected functions to return a str (or a tuple
including a str) when in the C++/Qt API a QString parameter would have been
modified.
In addition, API 2 has added two methods to QFontMetrics and QFontMetricsF,
widthChar() and boundingRectChar(), which take a str of length one and call
QFontMetrics::width() and QFontMetrics::boundingRect() with a QChar
argument. These were added because the width of a single character may be
different from that of a string that contains a single character, even if
the characters are the same.
--8<----8<----8<----8<----8<----8<----8<----8<--
Cheers,
ma.
_______________________________________________
PySide mailing list
[email protected]
http://lists.openbossa.org/listinfo/pyside
