On 2010-04-19, Matti Airas wrote:
> On 16.04.2010 17:58, ext Hugo Parente Lima wrote:
> > IMO, thinking with the foots in the implementation land, we have some
> > options, but I can't see a good one at the moment:
> >
> > - Provide both API's for the same python version: will add a lot of
> > complexity to the bindings implementation, and some points in APIv2 only
> > makes sense with python 3, so I don't know if this is really a option.
>
> Hmh, I see I'm being out-voted with this one... Oh well. :-)
My only vote is for API 2 with Python 3. (If the PySide guys get API 2
working with Python 2 that'd be great but not something that I care
about.)
> 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.
> How does PyQt deal with the issue when using API 2 on
> Python 2.x?
I don't know.
> Anyway, can't we simply accept regular strs by applying a default
> unicode conversion, or just requiring any input strings to be unicode?
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.
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.
> > - Provide different API for different versions: will be like a fork, but
> > the worst, we will fork the project ourselves but remaining with the
same
> > number of developers, so the development of the whole PySide will slow
> > down for sure.
>
> How do you feel about the development effort regarding this option as
> compared to the first one? Probably somewhat simpler but is the
> difference significant?
>
> > My opinion about this is a bit radical, just get one version of the API,
> > 1 or 2, I'm inclined to 2, adapt/improve them, then stay with them on
all
> > python versions.
>
> If only one would be picked, I'd also definitely opt for API 2. However,
> this contradicts with your claim that API 2 might not make sense on
> Python 2. :->
API 2 makes sense for Python 2 and 3; it is just that it might be harder
to implement for Python 2 and might involve having to make some
assumptions (i.e., you'd have to document how the str <-> QString
conversion worked).
> I suppose one single backwards-incompatible change could be acceptable
> if it happened very soon but how would we later on deal e.g. with the
> exception changes? Breaking the API repeatedly is obviously not an
> option. Should we then provide a way to simultaneously install different
> PySide major versions? How would this be implemented on the Python side
> (module naming)?
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!
(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?
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).
--
Mark Summerfield, Qtrac Ltd, www.qtrac.eu
C++, Python, Qt, PyQt - training and consultancy
"Advanced Qt Programming" - ISBN 0321635906
_______________________________________________
PySide mailing list
[email protected]
http://lists.openbossa.org/listinfo/pyside
