On 2010-04-19, Matti Airas wrote:
> On 19.04.2010 15:53, ext Mark Summerfield wrote:
> >> Is there any other issue with API 2 on Python 2.x than Python strings
> >> not being Unicode?
> >
> > The transparent conversions to/from QVariant + handling those few
> > methods that take mutable QStrings.
>
> Sure, but these should be identical on either Python version, no?
In an ideal world, yes. But keep in mind that only API 2 does these
automatic conversions, so PyQt + API 1 doesn't do them.
I think it would be great if PySide did automatic conversions to/from
QVariant for all Pythons. And in addition, for Python 2, supported the
QVariant class so that API 1 code would work with Python 2.
> > With Python 2.6 you can force str to be Unicode using
> >
> > from __future__ import unicode_literals
> >
> > But that won't help you if you want to support 2.5 of course.
>
> Yes, we want to, at least for some time.
OK, that'll make life a bit harder for the developers!
> > Unfortunately converting Unicode to/from 8-bit str isn't straightforward
> > since 8-bit str is using the local 8-bit encoding, so you'd have to do
> > the conversion accounting for that. Also, while Unicode has practically
> > every character, it doesn't quite have all of them, so you'd have to
> > decide what to do about characters that couldn't be converted.
>
> But we have to face the same conversion issues going from str to QString
> in any case, except that if it's done in the background, it'd be more
> opaque to the user.
No, Python 3 str is Unicode so str<->QString with Python 3 involves no
risk of changing the text. But Python 2 str is 8-bit local encoding so
might not round-trip to QString...
> > Breaking the API is not going to make anyone happy---but PySide is so
> > small at the moment that personally I think it is worth breaking it as
> > often as necessary to get PySide "right". Once PySide 1.0.0 comes out
> > then it is a different matter of course, and compatibility ought to be a
> > religion!
>
> That's a very good point: we could still regard it work in progress and
> make the changes we deem necessary.
>
> > (1) Is PySide a PyQt clone (possibly with compatible additions to make
> > it more Pythonic)?
> >
> > OR
> >
> > (2) Is PySide a Python/Qt bindings that closely resembles PyQt and is
> > largely compatible, but favors being more Pythonic over
> > compatibility?
>
> While complete compatibility has had its vocal proponents (even you,
> IIRC ;-)), I think (2) expresses the project goals and sentiments more
> closely. Compatibility is very valuable but we shouldn't follow PyQt
> blindly in cases we think we can make it better, IMO.
Yes, when you started out with PySide I was v. keen on complete
compatibility. This is convenient for existing PyQt developers and
easier for book authors!
However, if you are not too concerned about how easy it is to port from
PyQt to PySide, then why not go for the most Pythonic bindings possible,
while making porting from PyQt as easy as possible (by using the PyQt
API) when it doesn't conflict with making PySide Pythonic.
BTW My guess is that 99% of PyQt code is still Python 2 + API 1, so
those people are going to have some work to do to port to Python 3 + API
2 and/or to Python 3 + PySide.
> > If (1) then PySide must support API 1 for Python 2 and API 1 _and_ 2 for
> > Python 3.
> >
> > If (2) then PySide can choose its own API and provide documentation
> > and/or a pyqt2pyside tool to help people convert. In the case of (2)
> > then I would opt to be as Pythonic as possible, so have a single API
> > (i.e., API 2) + exceptions& anything else that makes it more Pythonic
> > than PyQt.
> >
> > I have no strong preference either way (and of course there may be other
> > possibilities). However, it would be _nice_ to be able to have
> > applications that could use PySide or PyQt just by using suitable
> > imports& if statements, but this would mean going the route of (1).
>
> I think there should be a middle ground for that as well, at least such
> that if one e.g. only resorts to PyQt API 2, the changes to PySide would
> be trivial.
>
> Of course, if we'd e.g. decide to go the route of the Python exceptions
> in PySide, it'd be a more complicated case...
Yes, using exceptions would be nice...
--
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
