Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More fine-grained control of docstring and comment length #906

Open
McSinyx opened this issue Feb 5, 2020 · 2 comments
Open

More fine-grained control of docstring and comment length #906

McSinyx opened this issue Feb 5, 2020 · 2 comments

Comments

@McSinyx
Copy link

McSinyx commented Feb 5, 2020

As discussed/hijacked in #344, I proposed to have an option to limit the length of docstring and comments:

  1. Multi-line docstring: max_doc_length, default to max_line_length (current behavior)
  2. Single-line docstring: max_single_doc_length, default to max_doc_length + 3 if max_doc_length is set, otherwise to max_line_length
  3. Comment block: max_comment_length, default to max_doc_length (current behavior)

Answer to @asottile

I don't think the complexity of a bunch of new settings is a good idea -- also your current proposal allows single line docstrings to extend beyond max_line_length

I added that to the proposal. My rational is, consider these

"""Something that span 72 columns.

Some additional description.
"""

"""The same first line."""

then the second case actually reaches 75 columns. I'm not sure about others, but I consider

"""Blah blah blah.
"""

to be quite distasteful.

Answer to @timj

I'm really happy with the current situation and have no problem forcing my comment lines to match the docstring constraint.

Generally, I have no problem with breaking comments, but in a few places like copyright headers, it's not very nice, like in AGPL or LGPL:

# foobar is free software: you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published
# by the Free Software Foundation, either version 3 of the License,
# or (at your option) any later version.
#
# foobar is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU Lesser General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with foobar.  If not, see <https://www.gnu.org/licenses/>.

As you can see, the second-last line is 74 columns, and breaking it in any manner makes it look awkward, especially when these should be consistent between different languages.

Also to @brianv0, what's your opinion on this?

@bstivers
Copy link

I like this proposal. The original "hijack" is from 2014. This one from a year ago. I can't believe there isn't any more input/progress on this topic.

For example, if using Click, the docstrings are automatically wrapped at the proper length when using --help. But when linting, it's possible to have a different look in the actual code if using say, Black, as the formatter with the default line-length = 88, or worse, 120 in Django.

I like constraints that help provide consistency across cli/sphinx/code, especially when it comes to appearance. Having a separate setting would provide that.

@sigmavirus24
Copy link
Member

@bstivers I can understand you're coming from a place of frustration but the tone of your comment reads to me as condescending and unnecessarily hostile. All it makes me want to do is reject this because why would I reward such shame-y comments with what you want to result from this.

There's been no progress on this because no one has been motivated enough to make progress on it. There hasn't been more input because, as I suspected at the time, this is an incredibly niche ask likely to only dramatically increase the complexity of pycodestyle to benefit less than 1% of users.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants