On 2010-04-16, 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"?
No, it _must_ specify "Python 3". API 2 won't work with Python 2 (at
least not nicely) because Python 2's str class is local 8 bit not
Unicode.
How about:
Adopt PyQt's API 2 for Python 3/PySide
Ah, but in view of what you write later on, then your title would be
fine as is.
> > 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.
I'm not at all keen on that.
For one thing, the idea is to get away from the QVariant class. For
another, using qVariant() should be very rare indeed.
> > 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?
I don't think that argument holds for PySide.
(1) PyQt already broke this rule;
(2) There are v. few PySide apps right now, so better to get it right
before the user base is too large.
> 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.
I can understand your concerns. But I don't see any nice way around the
fact that Python 2 strings are local 8 bit and Python 3's are Unicode.
> 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.
Sure, if you can manage it. I guess you could map QString to the Python
2 unicode type. I doubt that'll help people port later on though but at
least it would make API 2 available to Python 2 programmers which is
better than API 1. And making QVariant "disappear" should also be no
different for Python 2 than Python 3.
> 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.
I agree.
BTW Who is responsible for editing it now that it is on the web site?
PS the View document source link at the bottom doesn't work, at least
not for Firefox on Linux.
--
Mark Summerfield, Qtrac Ltd, www.qtrac.eu
C++, Python, Qt, PyQt - training and consultancy
"C++ GUI Programming with Qt 4" - ISBN 0132354160
_______________________________________________
PySide mailing list
[email protected]
http://lists.openbossa.org/listinfo/pyside
