issue_comments

This seems to be resolved so I'll close this issue. Feel free to post / reopen if you disagree.

Just for reference, both pytest and the standard library doctest runner allow running setup code: python @pytest.fixture(autouse=True) def custom_function(doctest_namespace): # the name of the function does not matter # add setup code here ... The official way to call the builtin doctest runner seems to be to add a if __name__ == "__main__" with a call to doctest.testmod() and to then call the module using either python <filename>.py or python -m <filename>. All code before the call to testmod can be used to set up the environment of the doctest.

Pandas breaks PEP8 (80 > 79) too then and Numpy is PEP8 compliant to one indent level (75 + 4) which I think is fine.

I see no point in temporarily changing settings as it will not work with doctest. I will work around it by printing numpy arrays instead.

Our default line width limit for text repr() is actually already 80 characters. This matches display.width from pandas, and is a little longer than what NumPy uses (75 characters).

You can definitely set a lower line width if you like for rendering repr() when copying and pasting into docstrings, using xarray.set_options.

I don't think we should change this overall, because copying and pasting into docstring is a relatively rare use of repr() compared to printing data in a console.

We ignore this error here:

https://github.com/pydata/xarray/blob/2bc8e33b319d54f9a6e89a88ac3161f4fb569fcf/setup.cfg#L109-L110

I think the argument is that a line lenght of 88 is much less likely to be too short: https://black.readthedocs.io/en/stable/the_black_code_style.html#line-length

Black defaults to 88 characters per line, which happens to be 10% over 80. This number was found to produce significantly shorter files than sticking with 80 (the most popular), or even 79 (used by the standard library). https://black.readthedocs.io/en/stable/the_black_code_style.html

I wonder why they don't reduce the indent size too if minimizing rows is of such importance.

The line width does make perfect sense if Black is the new de facto standard. I don't think it's the path of least resistance though. If 88 is used it will trigger other code style analyzers (it did for me) because they default to 79. PEP8 has been around for 19 years, black has a lot of work trying to persuade 19 years of people recommending following PEP8.

Have you updated the pep8speaks bot with this line length?

Thanks for the issue and the example.

Because we use black — and blacks increasing adoption in the python ecosystem — I think operation on its default 88 width is reasonable. Given the display width is currently 80, that gives us two tabs. I think that's probably OK. Are there cases where it doesn't work?

Seems the max width is defined in https://github.com/pydata/xarray/blob/43a2a4bdf3a492d89aae9f2c5b0867932ff51cef/xarray/core/options.py. Setting OPTIONS[DISPLAY_WIDTH] = 71 does the trick. Not sure where else this option is used though.