Any thoughts on implementing automated line wrapping as an optional post-processing step?

[NathanLovato]

Now that we have the post processing step in place after briefly checking how the black formatter handles line wrapping, perhaps we could have something like this eventually in this formatter at least as an option.

Black tries to fit entire expressions on one line and wraps using different strategies over multiple lines if that does not work.

It also turns line continuations into parentheses if they need multiple lines.

You can see examples and details on this page, in the top section: https://black.readthedocs.io/en/stable/the_black_code_style/current_style.html

As we already post-process the formatter...

[shadr]

I actually tried to add line wrapping today. Instead of as a postprocess I tried to do it as a preprocess step (so I could add one new line and then topiary will format it as a multiline statement), but this approach has less control over the final output. I will try to make it as a postprocess step instead in the following days. A few things that I discovered doing that:

1. formatting function definitions, function calls, arrays and dictionary is pretty easy ( unless there is a parenthesized expression )
2. parenthesized expression on the other hand is not :) there is more places where to put a line break, and something else also bothered me, but I forgot
3. doing line wrapping breaks tests, if we add a flag to skip line wrapping, should we add a way to tell a test to use specific flags (also opens a possibility for tests for code reordering feature) to preserve our current tests ?

[NathanLovato]

Wow, that's great! In preprocessing it might end up being overridden by topiary yes. And absolutely, wrapping expressions is going to be a fair amount of work/difficult. Don't hesitate to start real simple and build it through little touches. The code reorder feature is not perfect yet and neither is the formatter itself (but they work and help!).

I would recommend making the feature opt-in at first (while it's "experimental") so you can freely reshape it and iterate through testing.

Regarding 3., Ideally for sure we should add a way to test code reorder and also line wrapping. Perhaps even both in isolation and with topiary in the middle, to distinguish issues that would stem from other processing phases in the formatter?

Though to start with, even just testing the relevant functions (like reorder code works as a sort of standalone script almost) would be excellent already.