On dom, 2010-11-28 at 18:17 +0000, Phil Thompson wrote: > On Sun, 28 Nov 2010 18:26:58 +0100, Giovanni Bajo <[email protected]> > wrote: > > On dom, 2010-11-28 at 15:12 +0000, Phil Thompson wrote: > >> On Sun, 28 Nov 2010 15:35:38 +0100, Giovanni Bajo <[email protected]> > >> wrote: > >> > On lun, 2010-11-22 at 16:06 +0000, Phil Thompson wrote: > >> >> I've added a roadmap for SIP v5 at... > >> >> > >> >> http://www.riverbankcomputing.com/software/sip/roadmap > >> >> > >> >> Comments welcome. > >> > > >> > Hi, > >> > > >> > I'm concerned by this: > >> > > >> > ==================================================================== > >> > The code generator will be reimplemented using Python v3. It will be > >> > able to be used as a standalone application or a package. > >> > ==================================================================== > >> > > >> > This means that users of SIP will need to install Python v3 as a > >> > dependency to run sip, even for projects using Python v2. Additional > >> > build dependencies can really really be painful to handle. > >> > > >> > I suggest you revisit this, unless you plan to make it work with > Python > >> > v2 through 3to2 or similar. An alternative option would be to write > it > >> > in 2to3-friendly dialect of Python v2, so that in the future when you > >> > are ready to drop Python 2 support you can simply drop the original > v2 > >> > source code and use the generated version as new basis for > development. > >> > >> I don't see the dependency as a problem. There is no problem installing > >> Python v2 and v3 side by side on Windows. Linux distros have been > >> packaging > >> Python v3 to run alongside v2 for some time. > > > > Multiply that for different projects running different Python versions, > > requiring different SIP/PyQt versions, maybe different C++ compilers, > > and now different Python3 versions. > > > > Your statement is true for the simplest setups. I help people building > > stuff as part of my job (yes, it can be a job in itself :), and any > > additional dependency can cause problems, make the build system harder, > > and cause unnecessary slowdown in development. > > > > There are already strong dependencies between sip versions, Python > > versions and PyQt versions (and I'm ignoring Visual Studio issues, > > PyInstaller issues, build system issues, and whatnot), and I fear what > > might happen if we add another additional and incompatible Python > > version to the picture. > > > > As a concrete example, I'm working right now on an internal one-file > > custom build of Python bundled with sip/PyQt (+ other modules) as > > builtins, and a import hook to import sip modules (= they get > > transparently recompiled, much like pyximport does for Cython); by > > adding Python3 to the picture, one would need this internal Python build > > to ship with a Python3 within it. > > > > Now that I think of it, this might be less of a problem for me if SIP4 > > and SIP5 work together at the binary level. For instance, will it be > > possible to build PyQt4 with SIP5 and PyQwt with SIP4, and import them > > within the same process, pass objects back and forth, etc.? In this > > case, I could keep on using SIP4 wherever I feel like SIP5 would > > complicate build environments too much. > > That would work only until SIP5 needed to bump the major number of the > internal API.
... and if you don't plan to support SIP4 anymore after you release SIP5. > Of course the whole point of producing the roadmap and a migration plan > for SIP4 to SIP5 is to make it easy for things like PyQwt to move from one > to another in their own time. > > If you are suggesting that SIP5 should be implemented in Python2 rather > than Python3 then you are just creating the same "problem" for a different > sub-set of users. You are also expecting me to write new software in a > "dead" language. I specifically suggested to use a 2to3-friendly dialect of Python 2, so that Python 3 users can still benefit a native version of the sip code generator; 2to3 can even be integrated in distutils, and since you are planning to use distutils for distributing sip, Python 3 users would simply have the code converted automatically under the hood for them. The same could work for you the day that you decide to drop Python 2 support from SIP and PyQt (which I hope it is not even planned right now); just run 2to3 once and commit the resulting files. Alternatively, you can write Python 3 code and run 3to2, but I've never used this tool, so I can't really back it too much. I don't know what you've done with dip and Python 2.6, but using 2to3/3to2 is usually much easier on the development than restraining yourself to a subsect of Python which is both valid Python 2 and Python 3. But it's a matter of taste, I guess. -- Giovanni Bajo :: Develer S.r.l. [email protected] :: http://www.develer.com Blog: http://giovanni.bajo.it Last post: Compile-time Function Execution in D _______________________________________________ PyQt mailing list [email protected] http://www.riverbankcomputing.com/mailman/listinfo/pyqt
