Here goes:
http://www.pyside.org/docs/pseps/psep-0101.html
(I just notice the formatting is a bit messed up in a couple of places;
I'll fix them on Monday.)
At this point, a couple of comments:
On 16.04.2010 12:59, ext Mark Summerfield wrote:
Title: More Pythonic API for Python 3/PySide
This is rather generic. How about "Adopt PyQt's API 2 for PySide"?
It is possible to keep QVariant out of API 2 and still be able to solve
the problem that Richard raised. Here is an alternative syntax:
function(qVariant("ushort", value))
In other words, a dedicated function, qVariant(), that _always_ takes
two arguments (type, value). This would avoid the need to bring QVariant
back into API 2 and would also mean that tuples (like lists and dicts)
could be passed where a QVariant was expected without formality. With
this syntax, in most cases Python programmers would just pass Python
objects where QVariants were required, but in those rare cases where the
C++ type matters, the qVariant() function could be used.
How about having a qVariant class instead?
function(qVariant.ushort(value))
This would avoid using the stringified type names.
Matti Airas pointed out a disadvantage of this simplicity: that it means
that large applications need to be ported in one big go rather than
module by module (which using a PyQt-like API changing API would allow).
However, Detlev Offenbach questioned how difficult it would be in
practice, even with a large application. He cited the example of the
Eric IDE (which is v. large), pointing out that the conversion from
Python 2 with PyQt API 1 to Python 3 with API 2 took only three weeks,
with most of the problems unrelated to Python 3 or API 2.
I still want to argue this. :-)
Basically, I believe we should have very strong reasons for deviating
from the official (?) recommendations for porting libraries to Python 3:
http://www.artima.com/weblogs/viewpost.jsp?thread=227041
The arguments for making the API incompatible between Python versions
are due to developer (documentation?) and implementation simplicity and
more clearly promoting API 2 for the future, right?
While implementation might be more complex if we supported both APIs for
both Python versions, in my opinion the API 2 would already be promoted
sufficiently if the default version would be different for different
Python versions. Also, as Attila mentioned, we're still going to go with
Python 2.6 with the next Maemo/MeeGo Python release, and PySide will be
prominently used for providing both Qt and other API bindings. So, there
will be significant PySide use with Python 2.x, at least on some
platforms, at least for some time. That's why I also worry about the
upgrade paths and would like to provide both Python 2.x and Python 3.x
access to both APIs.
Would it make sense if both APIs were provided for Python 2 but only API
2 for Python 3? This would provide the easy upgrade, implementation
simplicity for Python 3 (at least ultimately), and strong promotion for
API 2.
Also, even if both APIs were supported, in my opinion it should be
perfectly sufficient if it was done on module level instead of class level.
Cheers,
ma.
_______________________________________________
PySide mailing list
[email protected]
http://lists.openbossa.org/listinfo/pyside
