Alternative design: hooks/entry-points vs monkey-patch

It occurred to me this evening that an alternative design is possible. Rather than monkey-patch black, we could just run black and then post-process the result. The post-processor would simply visit and correct all the string quoting. I'm not sure I like the idea of a "wrapper" but it is less invasive.

Maybe black could be "extensible" through hooks/entry-points in some way. The post-processing could be a supported feature.

I've thought about requesting minimal extension points / hooks in black, which I hope would be more acceptable than potentially asking for configuration settings they are unlikely to accept. That at least would obviate the need to monkeypatch, although we'd still have to control the invocation point to install our hooks. Still it would future proof us against changes in black that would break blue, such as the whole executor breakage we recently fixed.

I think I like that better than post-processing because I think we essentially need the same level of access to the AST rather than the raw source. With a post-processor, wouldn't we have to re-parse the source and re-implement all the efficiencies that are now in black to e.g. multiprocess all the source files, integrate with blackd etc.?

Yes, hooks/entry-points might be a good compromise if the configuration setting is rejected.