Russel says: Python 2 is the millstone for SCons 3.
I've been using 3.6 for all recent projects and loving it (async, f-strings, etc.), but what weight are we really carrying by supporting 2.x? Seems to me like most 3.6 features can be detected at runtime while still keeping back compat without too much extra work. But I may be missing something. -- Gary On Sat, Jul 21, 2018 at 7:37 AM Russel Winder <rus...@winder.org.uk> wrote: > On Fri, 2018-07-20 at 23:20 -0400, Bill Deegan wrote: > > Pretty certain Gary's with me in saying, > > SCons will support Python 2.7 and 3.5+ in (at least) the 3.x > > releases. > > Most likely through (at least) the end of 2018. > > You can add me to agreeing with that. > > > I know many who actively participate in SCons community live on the > > leading > > edge of OS and Python releases but many users do not. > > Also, there are still some rough edges to our Python 3 support. Until > > it's > > rock solid (and no one has found an issue for a while), dropping py > > 2.7 > > would be unwise. > > I see your finger pointing at me. :-) > > We have had not dissimilar maintenance debates in the Apache Groovy > community, especially now JDK is updated every 6 months instead of > every 6 years. Clearly there is a need to support people using ancient > three year old systems. Debian Stable and Ubuntu LTS really set the > timescales here, and the Python versions. Except that Travis-CI appears > to think using the most ancient Ubuntu LTS they can is a good thing. > > But then come the issues at the heart of the matter: If people are > using three or five year old platforms, will they be using the very > latest version of SCons? If they want the very latest SCons why can't > they install the very latest Python? If they are happy with the three > year old Python will they actually be happy with the three year old > SCons? If a distribution provides Python and SCons why is there any > interest in them updating anything? > > Groovy used to have a "we must be totally backward compatible" > obsession that was over the top, especially for me. Over the last year > the policy has changed towards something much better, and which has > allowed Groovy to progress much better in a highly dynamic world. > > OK so Java has the big difference that you distribute compiled > artefacts and there are only link time issues, whereas Python is > distributed as source so everything is compile time issues. But the > Groovy team have now begun to accept that "backward compatibility" can > be taken too far. For each major version of Groovy a lower limit is now > set and if people are not prepared to update their Java, then they have > to use the last version of Groovy that works with that version of Java. > > Python 2 is the millstone for SCons 3. The question is whether there > will be a 2.7.16 or whether 2.7.15 is really the last version. Also > will an organisation break ranks with PSF policy and pick up Python 2.7 > and keep it going? Would that matter for SCons? > > I can fully understand sticking with 3.5 at this time, but SCons > versions must be allowed to change the minimum Python version. Should > SCons 3.1 require Python 3.6 and drop support for Python 2.7? If yes > then people not on Python 3.6 simply stay with SCons 3.0.X. > > For me this is all about consistency: you can't demand cutting edge > SCons unless you are prepared to use cutting edge Python. > > -- > Russel. > =========================================== > Dr Russel Winder t: +44 20 7585 2200 > 41 Buckmaster Road m: +44 7770 465 077 > London SW11 1EN, UK w: www.russel.org.uk > _______________________________________________ > Scons-dev mailing list > Scons-dev@scons.org > https://pairlist2.pair.net/mailman/listinfo/scons-dev > -- Gary
_______________________________________________ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
