[PATCH] D154987: [lit] Implement PYTHON directive and config.prologue

[Joel E. Denny via Phabricator via llvm-commits]

jdenny added a comment.

In D154987#4529228 <https://reviews.llvm.org/D154987#4529228>, @sammccall wrote:

> I have to offer a dissenting voice here...

Thanks for explaining your view.

In D154987#4529228 <https://reviews.llvm.org/D154987#4529228>, @sammccall wrote:

> Almost all lit features have a python equivalent: CHECK vs check(),

How would a `check()` work?

> DEFINEs vs variables, `%if` vs `if` etc.

My hope was that people would gradually migrate away from lit constructs like `%if` and REDEFINE, which some people find ugly to use and complex in lit's implementation.  I do think DEFINE and simple lit substitutions will be around for a long time because they're useful with simple RUN lines.

> Now there are always several ways to do the same thing, it's unclear when each is best, and the inconsistency will make it hard to read & maintain tests across the repo in various dialects, which many people have to do.

Maybe, but most tools/languages eventually grow that issue.  An intended advantage is that people would be reading python instead of new add-ons for lit's own scripting language, which LLVM developers (understandably) keep wanting to propose.  That is, a lit with PYTHON should make tests easier to read and should make lit easier to maintain than a lit with its own evolving scripting language.

> It's possible to process lit shell tests with alternate implementations (without python!), I know of at least two...

I don't think I've heard about this.  Can you explain more?

> Python is a serious general-purpose programming language with tools available, but none of these tools work with python embedded in lit tests (not even syntax highlighting!).

That sounds like a nice integration to work on... instead of continuing to grow lit's own scripting language.

> The lit test runner supports having multiple types of tests (this is how we run gtest + shell tests).
> Could the tests you're targeting be written as actual python files, with an appropriate library of operations? (Some of this library could of course be shared with the shell test implementation).

Are you suggesting that, instead of embedding python inside C/Fortran/IR/whatever, people should embed C/Fortran/IR/whatever inside python?  Either way, libraries can be developed to minimize the complexity of python in the individual tests.  However, I think the latter would create greater inconsistency among lit tests than the former: just to add a loop to a shell command in an existing lit test, you would have to reorganize the entire test.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D154987/new/

https://reviews.llvm.org/D154987