[llvm-dev] Python 2 compatibility for utility scripts

[Fangrui Song via llvm-dev]

On 2019-12-17, Philip Reames via llvm-dev wrote:
>
>On 12/17/19 10:33 AM, Nico Weber via llvm-dev wrote:
>
>    On Tue, Dec 17, 2019 at 1:15 PM James Y Knight <jyknight at google.com> wrote:
>
>        On Tue, Dec 17, 2019 at 12:55 PM Nico Weber <thakis at chromium.org>
>        wrote:
>
>            On Tue, Dec 17, 2019 at 12:41 PM James Y Knight <
>            jyknight at google.com> wrote:
>
>                It sounds like you ran into a bug in the test infrastructure's
>                code to determine if python3 is supported. Fixing that might be
>                harder, but it only needs to be fixed once no matter how much
>                more python3 development there will be.
>
>            No, it was in some local.lit.cfg.
>
>        I see that now. Sure, in that case I suggest to fix whatever the issue
>        is and move it to common code, so that the "python3" feature
>        is correctly detected and available to any test.
>
>                Right now, most of our scripts were originally written for
>                python 2, so certainly it's easy for them to support python 2.
>                But, it was a lot of work by various people to port them all to
>                additionally work in python 3. And, in the future (or maybe
>                even now), people will be generally be writing python3 scripts
>                by default rather than python2. Certainly they ought to. 
>
>                I just don't think it's worthwhile to require all new such
>                scripts to continue to be written bilingually, unless doing
>                that extra work helps to serve users.
>
>                I'm not at all worried about a hypothetical case where we want
>                to ship a script that was written for python3 only. Firstly,
>                because that usually doesn't happen. But if it does, we can
>                port it then, or else we might just decide it's fine for it to
>                be python3 only.
>
>            You don't see any advantage to having a consistent language level
>            across the project? (See also the flang vs c++17 discussion.)
>
>        In this particular situatoin, correct. For these auxilliary scripts
>        which are not released or used to build/test released components, I see
>        no advantage to requiring these to support python2, anymore.
>
>    Well, I disagree :)
>
>    I'm curious what others think.
>
>Don't really care, but I have a mild preference for accepting patches to keep
>python2 working.  I wouldn't *require* scripts to work with python2, but I see
>no reason not to land patches if someone wants to put in the work.
>
>Philip

If some library-like Python scripts are changed to support without
introducing complexity, I certainly agree.

I think that particular patch actually achieves this goal. What I am
concerned of is that the patch changes the shebang from python3 to
python (may be a symlink to either python2 or python3), which means the
auxilliary script can more likely have different behaviors on different
people's machines.

 From my experience, making a script 2/3 compatible may be quite
challenging. A lot of complexity comes from str/unicode vs bytes/str
differences. The code can be made quite a bit cluttered.