[PyQt] SIP v5 Roadmap

[Giovanni Bajo]

On dom, 2010-11-28 at 18:17 +0000, Phil Thompson wrote:
> On Sun, 28 Nov 2010 18:26:58 +0100, Giovanni Bajo <rasky at develer.com>
> wrote:
> > On dom, 2010-11-28 at 15:12 +0000, Phil Thompson wrote:
> >> On Sun, 28 Nov 2010 15:35:38 +0100, Giovanni Bajo <rasky at develer.com>
> >> 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.
rasky at develer.com  ::  http://www.develer.com

Blog: http://giovanni.bajo.it
Last post: Compile-time Function Execution in D