On Sun, 28 Nov 2010 20:04:34 +0100, Giovanni Bajo <[email protected]> wrote: > 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.
I would expect to drop support some time in 2012. >> 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. This is what dip needs... http://www.riverbankcomputing.com/hg/dip/.hg/patches/ I tried 2to3 briefly when porting the configure.py scripts to Python3. I wasn't impressed - it made lots of changes that weren't needed. Maybe I just naturally write fairly neutral code. Phil _______________________________________________ PyQt mailing list [email protected] http://www.riverbankcomputing.com/mailman/listinfo/pyqt
