[PyQt] QVariant and Python list

[Mark Summerfield]

On 2008-05-30, Phil Thompson wrote:
> On Wednesday 28 May 2008 6:35:32 pm Laurent Léonard wrote:
> > Hi,
> >
> > I read QList and QMap are not implemented in PyQt, because of the
> > presence of Python lists and dictionaries.
> >
> > But how can I use QVariant to "encapsulate" Python lists and dictionaries
> > ? When I try to do it I get the following error message : "TypeError:
> > argument 1 of QVariant() has an invalid type"
>
> I'd be surprised if you got that error with the current version.
>
> There are a number of issues here which I'd like feedback on...
>
> The various QVariant ctors allow type convertors to have an effect, ie. in
> SIP terms they don't have the /Constrained/ annotation. For example,
> QVariant(const QStringList &) will accept a Python list of strings. I think
> this is a mistake as QVariant([]) will be treated as an empty QStringList
> but QVariant([0]) will be treated as a Python object.
>
> So I think every QVariant ctor that takes a Qt class should have
> /Constrained/ applied.
>
> However that would then mean that QVariant([]) would now be treated as an
> empty QList<QVariant> and still not as a Python object.
>
> For similar reasons QVariant({"abc": 0}) would be treated as a QMap, but
> QVariant({1: 0}) would be treated as a Python object.
>
> Therefore I also want to drop support for QVariant(QList<>) and
> QVariant(QMap<>) completely.
>
> The advantage is that anything that is not a fundamental type (int, float
> etc) or a wrapped type will be treated as a Python object and can be
> retrieved using toPyObject() - all very consistent.
>
> The disadvantages are that it is an incompatible change. It also becomes
> impossible to create a QVariant(QList<>) or QVariant(QMap<>) from Python
> (although I can't find a use case in Qt). I could add fromQVariantList()
> and fromQVariantMap() methods to get round the second problem.

I have a rather more controversial suggestion (so maybe for Python
3/PyQt). Why not kill QVariant and QStringList and QString altogether!
Trolltech did just that with Jambi (Java/Qt), for which they use the
native Java Object and Java String, etc.

No matter how carefully PyQt honours the buffer API you still hit nasty
problems from time to time. For example, if you use the gzip module with
a QString filename you get a corrupt file; but it works perfectly with a
unicode or str filename. But the point is that if PyQt only used unicode
(str in Python 3) and bytes (for QByteArray) and object (for QVariant),
none of those kind of subtle problems would arise. It would also put an
end to having to know which kind of string you have and converting
between the two kinds.

Of course QString has some methods that unicode/str doesn't have. That
was also true of Java String and Trolltech solved that by providing some
static methods (that accept and return Java Strings) to fill the gaps;
the same could be done in PyQt.

My 2c;-)

-- 
Mark Summerfield, Qtrac Ltd., www.qtrac.eu