I guess you eliminated the need for the regex module?

Yep, I was initially using branch resets like you did, but ended up with a solution that doesn't need it.

As long as we are cleaning up the regular expressions, it might be a good idea to replace numbered groups with named groups.

I did not know this was a thing, very nifty! Will explore using them. I'll still mull them over, but unfortunately for now named groups screw up a few instances where I re-use patterns inside of other patterns.

A seems like a lot of the code in test_special_cases could be simplified with functools.partial. Although I'm also wondering if so many levels of indirection are actually necessary in the first place.

Ahh partial seems problematic for the most part, given the edge cases that need handling and the non-obvious variable names i.e. binary ops in operator usually have a finicky (__a, __b, /) signatures. Generally there might be room to reduce the indirection.

I typically use UPPERCASE for compiled regex objects. I'm actually unsure how common this practice is, though.

Hmm, I've seen uppercase elsewhere, and re_*/r_* too. I like r_* but not religious about it.

We should remove the duplication in the function_stubs submodule. I think we can replace the whole thing with a single file using module-level __getattr__. Or we could just remove it entirely and require the use of signatures to access the stubs.

I'll have a quick look at replacing the submodule, but as I'm not tackling module stubbing/signature tests in this PR I won't prioritise this just yet.

It might be a good idea to have some (really fast to run) meta/smoke tests that we can add to the main array-api repo CI to make sure the signatures submodule doesn't break on us.

I do have a few hard, non-test assertions for all of this, but definitely something I can review.

Actually, I just realized the (git) submodule breaks the ability to vendor array_api_tests. I think we can make vendoring possible by allowing copying signatures into array_api_tests as a (Python) submodule. Or we can just copy it manually and commit it, similar to what generate_stubs.py does.

Hmm, as I'm sure you'd agree it'd be ideal if we didn't hardcode things from a maintenance perspective. I guess the question is if it's too annoying to ask users to pull and deal with an array-api submodule? I'd rather err on the side of maintainability, and maybe change tact if folk complain.

It would be helpful to have more comments in the code explaining what is going on, and short docstrings for all the internal helper functions.

Yep, once I stabilise things 😅

If we can't parse something, we raise a warning most times. This should tell us if parse_cond()/parse_result()/something else needs updating to cover any new special cases with unforeseen properties.

Just to be sure, this should already be the case with the existing generate_stubs.py, no?

Yep I believe generate_stubs.py communicates somehow when something can't be parsed.