On Friday 16 April 2010 10:33:51 Matti Airas wrote: > 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,
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. - 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. 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. So... what's the perfect solution? I don't know, maybe there isn't one, but we can get close to one. > ma. > _______________________________________________ > PySide mailing list > [email protected] > http://lists.openbossa.org/listinfo/pyside -- Hugo Parente Lima INdT - Instituto Nokia de Tecnologia
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ PySide mailing list [email protected] http://lists.openbossa.org/listinfo/pyside
