[llvm-dev] Python 2 compatibility for utility scripts
Fangrui Song via llvm-dev
llvm-dev at lists.llvm.org
Wed Dec 18 11:32:40 PST 2019
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>
> 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.
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
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.
More information about the llvm-dev