On 2010-04-16, Mark Summerfield wrote:
> Hi Matti,
>
> On 2010-04-15, Matti Airas wrote:
> [snip]
>
> > 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 have added a new paragraph to the rationale that answers this.
>
> The problem is that for Python programmers coming to PyQt/PySide for the
> first time API 1 seems completely unpythonic. The most basic types you
> deal with all the time in Qt programming are QString and QVariant, and
> if you access Qt via Python, API 1 forces you to be aware of this. Yet
> the distinction should not (and need not) matter to Python programmers.
> After all, in Python 3, str is Unicode (as is QString), so any
> translation necessary should be transparent and automatic. And a similar
> case applies to QVariant (which isn't needed in Python).
>
> For people who have huge applications to port, naturally API 2 involves
> a significant amount of work. But once it is done the code is much
> nicer, and less error prone (just try writing QString filenames to a zip
> file using the zipfile module!).
>
> For the long term, and for all those coming to PyQt/PySide, a more
> Pythonic API is very desirable.
>
> > > Exceptions Rather than Error Codes
> > > ==================================
>
> [snip]
>
> > 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.
>
> I agree. I've dropped it from my PSEP. I'm not planning to do another
> PSEP on exceptions since I think it would be better to adopt API 2
> first.
>
> > 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?
>
> I don't think PySide should follow PyQt and allow APIs to be changed per
> class per module. I think PySide should take a very simple route:
>
> Python 2 == API 1
> Python 3 == API 2
>
> That way no one gets confused.
>
> > > PyQt provides a means of changing the API on a per-class basis.
> >
> > Is it really on a per-class basis or per module?
>
> Oh yes:
>
> import sip
> sip.setapi('QString', 2)
> # If we are using Python 2, now we are using API 2 for QString, API
> # 1 for everything else
> # If we are using Python 3, we are using API 2 for everything
>
> It is very flexible, but IMO v. confusing too.
>
> > > 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.
>
> I've added a note about this.
>
--
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
