[PyQt] SIP v5 Roadmap

[Phil Thompson]

On Sun, 28 Nov 2010 20:04:34 +0100, Giovanni Bajo <rasky at develer.com>
wrote:
> 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.

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