Hi,
How silly of me, writing potentially controversial posts on the mailing
list last thing Friday afternoon and then leave for the weekend. Fire
and forget tactics, I'd say. :-) I'll try to address here the raised
concerns from my point of view.
Here, the issue has been about making disruptive changes at the Python 2
to Python 3 transition. I believe the impact of such a change would
depend on the current and future user profile of PySide.
In general, does porting of existing apps from Python 2 to 3 happen a
lot, or is Python 3 mostly used in new projects only? Assuming the
latter, the API incompatibility is not much of a concern, but if porting
is something that's done a lot, the API compatibility issue is very
real. Here, I would assume that Python 3 adoption predominantly happens
with new projects, but this is just my personal uninformed hunch. Of
course, Robert's concerns with creating unnecessary barriers between 2
and 3 are nevertheless really valid, since the skill set of working on a
certain API is a big investment for any individual developer, and
wasting that is something that shouldn't be lightly.
When breaking the API, we could investigate more the option of using
separate imports for the different versions. For example, we could adopt
"import qt.core" instead of "import PySide.QtCore" (I think this was
proposed in some internal discussion a few days ago--whoever was the
culprit, step forward. ;-)) in the case of the incompatible API and
implement the both APIs also in Python 3. The thing I'm really concerned
here is the amount of increased effort in supporting both APIs. Thus,
the disruptive 2->3 switch might still remain under consideration.
Another issue is migration of PyQt to PySide: does it happen, and will
it happen? This should be the prime factor in deciding whether we should
mirror the PyQt APIs in the future or not. So far, PyQt compatibility
has indeed been a major goal of PySide, but one could argue that the
compatibility level is already sufficient enough. In any case, whether
or not we should use our scarce resources in implementing the remaining
PyQt 4.5 APIs, should be a fact-based decision.
One might argue that for projects already having chosen PyQt, the
licensing is not an issue. GPL'd projects are not going to win much by
switching over, and for existing commercial projects, Riverbank's
license fees are very modest and it's implausible to assume they'll
begin switching over any time soon. (And neither should leeching their
customers be PySide's objective per se.) So, I'd assume PySide will be
more attractive to new projects (both FOSS and commercial) and to
existing projects switching toolkits. For them, API incompatibility with
PyQt don't matter that much. So, I'd assume the goal of blindly
mirroring PyQt APIs might not make sense in the long run. Of course, we
shouldn't break the compatibility on purpose either, so if the PyQt APIs
are found suitable for PySide in the PSEP process, there's nothing wrong
in adopting them. It's just that in my opinion the decisions should be
made on a case-by-case basis.
Cheers,
ma.
_______________________________________________
PySide mailing list
[email protected]
http://lists.openbossa.org/listinfo/pyside
