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. > Exceptions Rather than Error Codes > ================================== > > C++/Qt does not raise exceptions; it always returns error values or > indicates errors in other ways. > > A more Pythonic way to indicate errors is to raise exceptions. > > PyQt4 supports the existing C++/Qt way. > > If PySide was willing to be incompatible with PyQt4, at least regarding > Python 3/PySide programs, then PySide could raise exceptions when errors > occur. (For example, for any class that has an errorString() method, > PySide could raise an exception with the error string's text as an > attribute.) In my opinion the topic of exceptions is somewhat unrelated to the other content in the PSEP draft and I'd prefer having it in a separate PSEP instead of bundled with the current one. The proposal of using errorString()s as a giveaway is an interesting one, but how about all the functions returning a boolean indicating success or failure? For example, I believe QDir.mkdir() should ideally throw an exception on failure instead relying on a return value. As you said, this would be a major deviation from PyQt. How should it be implemented? As API 3, using the same mechanism to choose between the APIs as with 1 and 2? As a different module name? Would it be possible to provide interoperability between the exception style API and the classic one? > PyQt provides a means of changing the API on a per-class basis. Is it really on a per-class basis or per module? > 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. 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
