[Scons-dev] Why we need to release separate SCons3 for Python 3

[Gary Oberbrunner]

On Fri, Feb 22, 2013 at 6:29 PM, anatoly techtonik <techtonik at gmail.com>wrote:


> I like you enthusiasm and desire to push Python 3 forward, but I must warn

> that wrong move will kill many existing SCons users. If Blender + few more

> projects will not use SCons anymore, I won't be here too.

>

> Do you think that all existing users know the intricacies of 2 to 3

> compatibility?

> Do you think they will be willing to port their existing scripts to Python

> 3 and know how to do this properly?

> Do you really want them to know about generators and other stuff that

> changed behavior and don't give immediate syntax errors like print?

>

> For example, where do you think can be a problem in this completely

> obvious and working Python 2 code?

> d = {"z":23, "x":21}

> d.items()[1]

>

> This code won't work in Python 3, and hence SConstruct will fail as well.

> Can you explain users how to patch all these uses?

>

> I expect that users who faced with non-obvious porting scenario will ask

> themselves - why do I continue to use SCons and deal with the problem it

> delivers with its poor 2 to 3 transition management and not learn something

> new instead and rewrite all this stuff in waf, gyp, cmake or some of those

> - http://en.wikipedia.org/wiki/List_of_build_automation_software ?

>


As long as existing users stay with Python 2 (2.7 specifically), they
should not have to do anything.  Things should continue working just as
they do today, if we do our job right.  Today, SCons users cannot use
Python 3 at all.  This port should *allow* them to use Python 3 *if and
when* they decide the time is right. In the case of a SConscript that is
shipped into the wild for untrained people to use, those SConscripts won't
run on python3 today (with syntax errors).  Writers of such SConscripts
should probably just check the python version right at the top and refuse
to run on python3 until the script is ported.

I think that should cover your scenario above, with one major exception:
users who require python versions older than 2.7.  Those users will have to
keep using SCons 2.3, and not move forward until they are ready at least to
install 2.7 (or 3.x).

(Note that some simple SConstructs that just call the SCons API functions
and don't do much python themselves may just work.  But we can't promise
that, because people can use any python they want in their
SConstructs/SConscripts).

After reading the above, do you still think this is a poor 2-to-3
transition management scheme?

-- 
Gary
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://two.pairlist.net/pipermail/scons-dev/attachments/20130222/58d4a957/attachment-0001.html>