Opinion first - I don't see a need to change PEP 8. I recommend 100 char
width for Python, which is acceptable under PEP 8 anyway. I think the real
limit should be around 70 characters per line, not including leading
white-space, but I realize that's impractical.
I work mostly at 100 character line width, and the question of line width
came up for me recently. Otherwise, I follow PEP 8. I want to see where,
and why I exceed 79 chars, so I dove into a decently sized module file of
mine and tallied the results. This is what I found.
563 total lines
448 non-blank lines
For the non-blank lines:
49.6 characters per line on average
36.7 non-leading-whitespace characters per line
13.1 leading spaces per line on average
15.5% of lines exceeded 79 chars.
The 69 lines that exceeded 79 characters fell into the following
categories, listed according to how annoying they would be to fix.
1 - with statements
I have a with statement that contains two context managers "with open(blah)
as b, open(foo) as f:". There isn't a really good way to wrap this without
adding another with statement or a backslash.
3 - function calls
Function calls, even with the arguments put one per line, often exceed 80
(and sometimes 100) character limit. The issue tends to be a combination of
tabbing, kwarg names, and the context in which all of this is used. It's
often unavoidable.
variable = some_class.method(argument=value,
argument2=value)
5 - Overly deep logic
There were a couple of blocks of code that should have been pushed into
separate methods/functions. I do occasionally run into issues where there
simply isn't room (in 79 chars) for the logic required, and that logic
can't reasonably be separated out.
8 - Format calls
While I love the new format syntax, I almost always end up moving the
format call to a new line with 4 spaces of extra indentation. These were
instances of when I didn't.
21 - Comments
There's plenty of space for readable comments in most cases. Under several
nested scopes, however, the space gets pretty tight. Those extra 20 chars
go a long way.
12 - Strings
Like comments, having a few extra chars for strings (mostly exception
messages in this case) goes a long way when even moderately nested.
2 - Chained conditionals
if A and B and C
Should have been:
if (A and
B and
C):
16 - Doc strings
These are easily fixable with no change in readability, and rarely have
issues with padding.
On Wed, Feb 20, 2019 at 12:57 PM Chris Angelico <ros...@gmail.com> wrote:
> On Thu, Feb 21, 2019 at 6:48 AM Jonathan Fine <jfine2...@gmail.com> wrote:
> > Here's a suggestion, at least for people projects that use black.py
> > (such as Samuel's). It is to use black.py with a line-length of say 80
> > characters for code that is saved in version control. And when editing
> > code, use whatever line-length that happens to suit the tools you are
> > using.
> >
> > Indeed, like a word-processor, one could use black.py to 'line-wrap'
> > the Python code to what is the current width of the editor window.
>
> From my experience (granted, I work heavily with students, so maybe
> it's different if everyone involved in the project has 5+ or 10+ years
> coding), autoformatters are a blight. They take a simple, easy-to-find
> missed parenthesis, and completely obscure it by reindenting the code
> until it finds something unrelated that seems to close it. The
> indentation in the code of even a novice programmer is valuable
> information about *programmer intent*, and throwing that away
> automatically as part of checking in code (or, worse, every time you
> save the file) is a bad idea. Easy bugs become hard.
>
> Of course, if you assume that everything in your code is perfect, then
> by all means, reformat it however you like. If you're 100% confident
> that nobody writes any buggy code, then the formatting doesn't matter,
> and you can display it in whichever way looks prettiest. But if you
> appreciate ways of discovering bugs more easily, preserve everything
> that represents the programmer's intention.
>
> ChrisA
> _______________________________________________
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
Paul Ferrell
pfl...@gmail.com
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
