This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author abartlet
Recipients Anthony Sottile, abartlet, miss-islington, pitrou, serhiy.storchaka, vstinner
Date 2020-03-02.21:37:21
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1583185042.67.0.363140659319.issue37330@roundup.psfhosted.org>
In-reply-to
Content
Thanks for the reply.

To clarify, it is best to understand where Samba thinks of itself in terms of Python.  We use python, but we don't really think of ourselves as a python project, and while we have some developers with a depth of experience in the language, most of us just use it as a tool to get things done, in particular to build Samba.

Samba has a build system built in Python, called Waf.  Samba uses waf to build the project (particularly the C parts), and our build of the C binaries is portable back to Python 2.6.  

Often in Samba we find bugs.  This might come as a shock! ;-).  Many of those bugs are regressions, and so it is useful to build old versions, sometimes 7 year old versions, to confirm if/when the behaviour regressed.  We are able to do this, with only one patch to address a perl behaviour change, even on a modern Ubuntu 18.04 system, all the way back to 2013.  

I terms of 'but this has been deprecated for years', Samba has only had releases been able to even use Python3 in the build system for a year (first committed to master in July 2018).

Nobody in Samba was aware of any DeprecationWarning and for better or worse we only knew about the issue once our builds failed in Fedora.  We are incredibly grateful that Fedora tried a rebuild with the alpha version of Python 3.9 as otherwise we would find out only after this was well baked into a release.

Thankfully we don't need universal newlines, but no matter if we need them, old versions of Samba will fail to build without a fix-up patch.

More importantly, I think it is unlikely that Samba is the only software to have used this feature, intentionally or otherwise, or to be in this position.  

While not as critical here, for context as to why we support Python 2.6 to build, it should be noted that retaining this compatibility was a critical part of being able to get consensus to otherwise move to Python 3.4.
History
Date User Action Args
2020-03-02 21:37:22abartletsetrecipients: + abartlet, pitrou, vstinner, serhiy.storchaka, Anthony Sottile, miss-islington
2020-03-02 21:37:22abartletsetmessageid: <1583185042.67.0.363140659319.issue37330@roundup.psfhosted.org>
2020-03-02 21:37:22abartletlinkissue37330 messages
2020-03-02 21:37:21abartletcreate