How to limit line-length when creating outputs for doctest using --doctest-plus-generate-diff=overwrite

[d-chris]

Question

is it possible to limit the line-length of the output created, using --doctest-plus-generate-diff=overwrite

ruff complains about the total length and i didn't find a settings to wave E501 for doctest outputs.

python-validators/validators#417 (comment)

Solutions

• automatically let doctest-plus add an optional noqa: E501
• format the output in a way, linter does not complain

how do you guys handle this?

[pllim]

We cannot assume all packages that use this package follow that rule nor know how the max length they choose (I mean, we could but combing through all the possible settings for arbitrary repo is painful and out of scope). Can't downstream fix style manually after generating this diff? It doesn't have to be perfect on the first go.

[bsipocz]

I would pass this on to ruff to deal with it and definitely would prefer not to pepper noqa into the generated outputs.

(a quick googling suggests that they have some dynamic rule sets that deals with long docstring lines. Otherwise, in my experience, this function already generates reasonable looking outputs for ellipsis included in the middle).

All that being said, if you add a new linelenght param I would consider adding it. --doctest-plus-generate-lineleght or a similar mouthful.

[d-chris]

so basically you guys never had that kind of issue/problem? 🤔

[pllim]

I haven't come across the need to use this yet as it is pretty new feature and the docs I maintain were written long ago. So I'll defer to @bsipocz and @seberg . 😅

[bsipocz]

I often use this for astroquery/pyvo, and never run into the particular issue. I do deal a lot with long table rows but the outputs generated were always reasonably ellipsed so it never really triggered a code style check failure (but we also don't use ruff/black and such overly opinionated formatters for those packages).

[seberg]

Not sure, I have never actually used it myself (I was hoping to for NumPy to fix the scalar reprs, but since there will be some other quirks to fight with in NumPy, I never did...)

Some line-lenght option seems reasonable, although I am not quite sure if it is always obvious how to even wrap the lines?
(TBH, I am not even sure how to do this manually without failing doc-tests. Is there a "line continuation" for output?)

[bsipocz]

I am not quite sure if it is always obvious how to even wrap the lines?

I'm not sure we want to wrap lines ever, but to force ellipses into them?

[seberg]

Yeah, but then you need a heuristic for what to omit? We do allow hooking into the replacement, IIRC, so maybe this would be an example for such a hook? (I.e. even just modifying the existing example stub that came from my fight with numpy)
(Check the readme, the diff-hook can replace got with something containing an ellipsis if long.)

[bsipocz]

I would only support such a line-leght option if it is strictly opt-in. So ideally no change to the default behaviour.