On Sat, Oct 3, 2009 at 12:41, Matti Airas <[email protected]> wrote: > 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?
There is not much of *any* Python 3 usage in production at this point in time. The majority of open source packages that are on PyPI for Python 3 have been ported from 2 to 3 and still support Python 2.x. Porting to Python 3 will probably be the majority activity as people migrate to Python 3. Even new projects use old code bases. However, many people will be sticking with Python 2.x a number of years from now. > 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. Are you going to drop Python 2.x support? If not, then you are still maintaining two APIs. > 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.) There are other restrictions on the PyQt commercial license besides the price. You cannot distribute the commercial PyQt libraries such that the user can write GUIs using them. This greatly limits the dynamism and attraction of using Python in the first place. Most of the applications my company makes embed an interactive prompt into the GUI so the users can manipulate their data interactively and also write GUIs to plug into the application. As for open source projects, not all of them are GPLed. Both Qt and PyQt have clauses in their license that explicitly allow the application code to be under more liberal licenses like BSD. We have made use of this and have BSD Python code using PyQt. There are a number of other Python projects that have done the same. We would love to be able to move to an LGPLed PySide as more fitting our license desires. > 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. I am happy to see some well-deliberated API changes. I just want to be clear that tying them to the Python 3 transition is not a benefit to anyone and is a substantial detriment to a number of people. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco _______________________________________________ PySide mailing list [email protected] http://lists.openbossa.org/listinfo/pyside
