[Scons-dev] Python 3 strategy

Tim Jenness tjenness at lsst.org
Mon Jan 25 10:59:21 EST 2016


> On Jan 25, 2016, at 05:29 , William Blevins <wblevins001 at gmail.com> wrote:
> 
> 
> 
> On Mon, Jan 25, 2016 at 9:39 AM, Russel Winder <russel at winder.org.uk <mailto:russel at winder.org.uk>> wrote:
> I am having difficulty making a decision…
> 
> The earlier Python 3 branch is founded on using six. At the time a good
> decision. Now however we have agreed that 2.7 is the base version and
> thus future rather than six is the better tool for Python 3. This
> brings into doubt the python3-port branch as a good base of operations.
> 
> William has done some work changing the python3-port branch, as have I,
> all based on the massive previous work. Despite all this effort I
> wonder if we have the right base to progress further. Maybe we have and
> carry on, but now is the time to stop before much more effort goes in
> if this is not the way forward.
> 
> The alternative is to abandon the current python3-port and start again
> from default based solely on future.
> 
> Instead of having a separate branch, let us work solely on default,
> turning it first into a Python 2.7 only thing using futurize to prepare
> the ground. This is really an extension of what is currently happening
> of course, but with a turbo charger. Let us insist that the SCons
> default branch is "futurize -1" with all __future__ imports in place,
> so that all Python 2.7 code is using Python 3 semantics where
> possible.
> 
> I think this is reasonable, but I don't know what effort has been made prior to now.
>  

As I said, the “-1” is completely safe as it is just modernizing from python 2.6- to 2.7.

> 
> This can happen within the current infrastructure effectively
> unchanged. Obviously all CI should be green with each changeset. I
> suspect it will not run under Python 3 in this form.
> 
> When this is done, we can add the "futurize -2" with the dependency on
> future, obtained not by vendorizing but by package management install.
> This should leave the Python 2.7 CI still green – assuming all the CI
> servers have future installed. (With Codeship and Drone this is handled
> by using a requirements.txt file in the usual pip-ish way.) Then the
> work of getting a Python 3 CI green can happen, with the Python 2.7 CI
> always green.
> 
> I'd prefer to make a solid attempt to not have a dependency of future if possible.
> 

To do that you will find that you have to write a lot of support code that handles the version differences. future has already done that though.

> Once it is added, chances are it will never be refactored out...
>  

The big difference between future and six is that in future the code you end up with looks like python3 code with some imports at the top (which are mostly no-ops on python3). With six you find that your code is full of six calls which it seems to me would be harder to remove.

— 
Tim Jenness

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist2.pair.net/pipermail/scons-dev/attachments/20160125/60910e5e/attachment.html>


More information about the Scons-dev mailing list