Are there any plans to generate the various operation interfaces or attribute interfaces in the MLIR PyBinds?
I have none.
The current user base of the python bindings is split between folks using it primarily for generation of IR and those trying to implement compiler tooling against the IR in Python.
I’m in the former camp and what we have is serviceable for that (plus “light” IR manipulation). As one of the original authors of it, I’m happy to pass the baton to anyone who wants to take it further – but with the caveat that IR generation capabilities and overheads need to not be regressed with additional feature development.
As another of the original authors, I’m happy to participate in the design discussions and reviews, but may not have the bandwidth to write code myself.
I’m am mostly in the same camp as Stella and see Python API as a way to construct or inspect IR, but I can also see it driving existing transformations, in particular by building on the transform dialect.
It is an interesting question whether the IR transformation APIs we have designed in C++ still make sense in Python. I suspect there may be more idiomatic forms that could require rethinking some levels of the API.
Who’s in this camp? Is that me? I don’t think of myself as such but maybe I’m confused about what camp I’m in 
Lol, wasn’t pointing my finger in any direction specifically… But if I was referring to anything it was some of the stuff on the circt side which was more exposing some of the internals to end users and such. Not that there is anything wrong with that, but in my experience, some of the more, let’s say… Adventurous uses of the API start to run pretty squarely not just into how the python API itself was setup but also would require substantially more backing C APIs. And that may signal that we have a level or type of API missing for those use cases to work well.
Iirc, the same basic friction existed with the original llvm python API over a decade ago: it even resulted in a fork (llvmlite) focused purely on emission and systematic integrations (and if used for that, claimed a lot of performance savings).
Ah haven’t kept up with that.
Adventurous uses of the API start to run pretty squarely not just into how the python API itself was setup but also would require substantially more backing C APIs.
I used to dream of a world where all the C++ APIs were readily available through Python. I still dream about it but I have no plans to start binding everything (and no clue how to get that kind of coverage otherwise).
(on the contrary, I was away for a while and really appreciated many of the ergonomic upgrades you’ve made over the months… Made many things nicer. Thank you)
1 Like
Yeah, I think that would be a very different kind of API. I certainly don’t have the stamina to attempt it 