On Donnerstag, 15. April 2010, Matti Airas wrote: > On 15 April 2010 16:26, Mark Summerfield <[email protected]> wrote: > > PyQt4 provides two different (and incompatible) APIs. API 1 is the > > original API and the one supported by PySide. API 2 is a new Python > > 3-specific API that is much more Pythonic. This PSEP proposes that PySide > > adopt PyQt4's API 2 for when PySide is used with Python 3. > > Hi Mark, > > Thanks a bunch for the PSEP! I had a busy day at work today and > couldn't comment your proposal there. I'll add your draft to the > (short) list of PSEPs tomorrow. I'm dead-tired now, but some comments, > nevertheless: > > There were ardent objections on this mailing list half a year ago when > we proposed to make an API break while switching to Python 3. I became > convinced about the reasoning that there should be no API breaks > coinciding with the Python version change since they would make > porting from Python 2 to Python 3 much more difficult. > > ... oh. There's actually PSEP 5 regarding this [1]. I told you I'm tired. > ;-) > > [1] http://www.pyside.org/docs/pseps/psep-0005.html > > Following the conclusions of that discussion, I would instead propose > that the new API is implemented both in Python 2 and Python 3 and just > a suitable mechanism for selecting between the two is chosen. Isn't > this the way it is done in PyQt as well, anyway? To be practical, I > think PyQt's approach of defaulting to different APIs in different > Python major versions is perfectly sensible as it does not introduce > any significant obstacles for porting applications.
I would opt for the API change in Python3. I did port my eric IDE from Python2 to Python3 in about 3 weeks including the change from PyQt API v1 to v2. Actually the most issues I had was with QByteArray and conversions from and to it, which is not API related. Doing the API switch together with the Python switch would give a clear porting direction. ... > > > PyQt provides a means of changing the API on a per-class basis. > > Is it really on a per-class basis or per module? It is on a per-class basis and has to be done before the very first import of a module containing these classes, i.e. it's best to do the switching in the main script. > > > PySide could offer a similar mechanism, but this would mean that > > programmers might end up with Python 3/PySide programs that used the two > > different APIs, one in some modules, and the other in other modules. > > > > PySide should not offer such a mechanism, but should instead support API > > 1 for Python 2.x and API 2 for Python 3.x to avoid confusion. (If users > > demanded an API changing mechanism, it could be added later.) > > Due to the reasoning presented earlier, in my opinion there should be > means to select the API independent of the Python version. I see the > point about having different API versions in different modules. > However, if the implementation issues allow for that, wouldn't it > provide the developers actually an easier upgrade path between the API > versions? It'd be much easier to upgrade different modules one by one > instead of huge monolithic changes. The upgrade isn't actually made more difficult (s.a.). > > Anyway, I'll try to be an impartial editor and make your proposal a > PSEP in the original form. :-) > > Cheers, > > ma. > _______________________________________________ > PySide mailing list > [email protected] > http://lists.openbossa.org/listinfo/pyside > Regards, Detlev -- Detlev Offenbach [email protected] _______________________________________________ PySide mailing list [email protected] http://lists.openbossa.org/listinfo/pyside
