On 2010-04-15, Richard Dale wrote:
> On Thursday 15 April 2010 02:26:32 pm Mark Summerfield wrote:
> > No QString, or QVariant
> > -----------------------
> >
> > The key difference between the APIs is that API 2 does not make QString
> > or QVariant available to programmers, instead using Python 3's native
> > str type for strings, and any Python class for QVariant.
>
> Sometimes you need a C++ specific type wrapped in a QVariant to make a
> method work correctly. For instance, the call might need a ushort type
> which has no direct equivalent in Python . If you pass a Python integer
it
> will be converted to a QVariant with a C++ int wrapped inside it, and the
> call expectng a ushort might not work.
>
> So I think you need some way of forcing the correct sort of QVariant to be
> created, probably by having a QVariant constructor where you pass a string
> with the C++ type, along with the Python value as another argument. Or a
> tuple of the type name string, followed by the python value that could be
> passed as an argument everywhere a QVariant was expected.
>
> If 'val' is an integer and we wanted a ushort based QVariant for the foo()
> this won't work:
> foo(val)
>
> So it needs to be something like this instead:
> foo(QVariant('ushort', val))
> foo(('ushort', val))
>
> -- Richard
I am not aware of PyQt supporting this. So if it were added to the PSEP
it would be above and beyond PyQt compatibility (which is fine). But can
you provide any real use cases to justify its inclusion?
--
Mark Summerfield, Qtrac Ltd, www.qtrac.eu
C++, Python, Qt, PyQt - training and consultancy
"Rapid GUI Programming with Python and Qt" - ISBN 0132354187
_______________________________________________
PySide mailing list
[email protected]
http://lists.openbossa.org/listinfo/pyside
