<div dir="ltr"><div dir="ltr"><div dir="ltr">First of all, thank you so much for taking the time to do some actual analysis!<br>I only have one thing to add:<br><br>[Paul Ferrell]<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">3 - function calls<br>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.<br>variable = some_class.method(argument=value,<br> argument2=value) </blockquote><div><br></div><div>This reminds me of a bit that shows up often in <a href="https://www.youtube.com/watch?v=B3b4tremI5o&t=7m45s">Kevlin Henney's talks</a>.<br><br>A better way to list arguments is only one indentation level above the current:<br><br><font face="monospace, monospace">variable = some_class.method(<br> argument=value,</font></div><div><font face="monospace, monospace"> argument2=value)</font><br><br>Trying to match the indentation of the opening line is less readable and less robust to refactoring:<br><br><div><font face="monospace, monospace">variable = some_class.method(argument=value,</font></div><div><font face="monospace, monospace"> argument2=value)</font></div></div><div><font face="monospace, monospace"><br></font></div><div><div><font face="monospace, monospace">var = cls.method(argument=value,</font></div><div><font face="monospace, monospace"> argument2=value)</font></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 20, 2019 at 4:52 PM Paul Ferrell <<a href="mailto:pflarr@gmail.com">pflarr@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div>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. <br></div><div><br></div><div>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. <br></div><div><br></div><div>563 total lines</div><div>448 non-blank lines</div><div><br></div><div>For the non-blank lines:</div><div>49.6 characters per line on average</div><div>36.7 non-leading-whitespace characters per line</div><div>13.1 leading spaces per line on average<br></div><div>15.5% of lines exceeded 79 chars. <br></div><div><br></div><div>The 69 lines that exceeded 79 characters fell into the following categories, listed according to how annoying they would be to fix.</div><div><br></div><div>1 - with statements</div><div>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.</div><div><br></div><div>3 - function calls<br></div><div>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.</div><div>variable = some_class.method(argument=value,</div><div> argument2=value) </div><div><br><div>5 - Overly deep logic</div><div>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.<br></div></div><div><br></div><div>8 - Format calls</div><div>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.</div><div><br></div><div>21 - Comments</div><div>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.<br></div><div><br></div><div>12 - Strings</div><div>Like comments, having a few extra chars for strings (mostly exception messages in this case) goes a long way when even moderately nested.<br></div><div><br></div><div>2 - Chained conditionals</div><div>if A and B and C</div><div>Should have been:</div><div>if (A and</div><div> B and <br></div><div> C):<br></div><div><br></div><div>16 - Doc strings</div><div>These are easily fixable with no change in readability, and rarely have issues with padding.<br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 20, 2019 at 12:57 PM Chris Angelico <<a href="mailto:rosuav@gmail.com" target="_blank">rosuav@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, Feb 21, 2019 at 6:48 AM Jonathan Fine <<a href="mailto:jfine2358@gmail.com" target="_blank">jfine2358@gmail.com</a>> wrote:<br>
> Here's a suggestion, at least for people projects that use black.py<br>
> (such as Samuel's). It is to use black.py with a line-length of say 80<br>
> characters for code that is saved in version control. And when editing<br>
> code, use whatever line-length that happens to suit the tools you are<br>
> using.<br>
><br>
> Indeed, like a word-processor, one could use black.py to 'line-wrap'<br>
> the Python code to what is the current width of the editor window.<br>
<br>
>From my experience (granted, I work heavily with students, so maybe<br>
it's different if everyone involved in the project has 5+ or 10+ years<br>
coding), autoformatters are a blight. They take a simple, easy-to-find<br>
missed parenthesis, and completely obscure it by reindenting the code<br>
until it finds something unrelated that seems to close it. The<br>
indentation in the code of even a novice programmer is valuable<br>
information about *programmer intent*, and throwing that away<br>
automatically as part of checking in code (or, worse, every time you<br>
save the file) is a bad idea. Easy bugs become hard.<br>
<br>
Of course, if you assume that everything in your code is perfect, then<br>
by all means, reformat it however you like. If you're 100% confident<br>
that nobody writes any buggy code, then the formatting doesn't matter,<br>
and you can display it in whichever way looks prettiest. But if you<br>
appreciate ways of discovering bugs more easily, preserve everything<br>
that represents the programmer's intention.<br>
<br>
ChrisA<br>
_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/codeofconduct/</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail-m_-1049524803147314604gmail_signature"><div dir="ltr"><div><div dir="ltr">Paul Ferrell<div><a href="mailto:pflarr@gmail.com" target="_blank">pflarr@gmail.com</a></div></div></div></div></div>
_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/codeofconduct/</a><br>
</blockquote></div>