On 16.04.2010 18:25, ext Mark Summerfield wrote:
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.
I'd just drop the slash and either use "Adopt PyQt's API 2 for Python 3
PySide" or "Adopt PyQt's API 2 for PySide on Python 3". You're the
native English speaker and professional writer, you choose. :-)
(Assuming I'm permanently out-voted, that is.)
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.
Actually, what would your qVariant() function return? A QVariant object?
In that case, it wouldn't make much sense to just instantiate QVariant
directly. The same obviously applies to my qVariant idea.
If QVariants are to be avoided, then Richard's tuple syntax might work.
But I wonder would it be just clearer to use QVariant explicitly when
absolutely required?
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;
But only very slightly and in a manner that doesn't really hinder
portability as you can use either API on either Python version.
(2) There are v. few PySide apps right now, so better to get it right
before the user base is too large.
That's a fair point.
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.
OK, this was the thing I was asking in reply to Hugo's mail. So, to
summarize, there shouldn't be major syntactical issues in providing both
APIs for either Python versions (if deemed necessary), but the
implementation is a completely different beast whatsoever.
Due to the implementation simplicity, I'm kinda keen on toying with
Hugo's proposal of just picking a single API version and sticking to it
but the best upgrade strategy after the initial break is still unclear
to me.
BTW Who is responsible for editing it now that it is on the web site?
According to P[S]EP 1, the PSEP author (i.e., you) is responsible for
making updates to the content. It's just nice to have it available
formatted somewhere, and now that it's there, we get version history as
well.
I'll just make stilistic changes by myself, e.g. fixing the reST
formatting I promised to do.
PS the View document source link at the bottom doesn't work, at least
not for Firefox on Linux.
Thanks, I'll look into it right away.
ma.
_______________________________________________
PySide mailing list
[email protected]
http://lists.openbossa.org/listinfo/pyside
