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?
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.
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.
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.
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...
Cheers,
ma.
_______________________________________________
PySide mailing list
[email protected]
http://lists.openbossa.org/listinfo/pyside
