On Thu, Feb 21, 2019 at 12:01 PM Raymond Hettinger <
raymond.hettin...@gmail.com> wrote:
> I concur. We now put expressions in f-strings and have assignment
> expressions that easily spill over 80 characters if one uses all but the
> most compact variable names. Comprehensions tend to make expressions
> longer. Queries and filters in Pandas also easily spill over. The 80
> character limit pre-dates these evolutions of the language.
>
> In particular, the case where I most want to let people run with long
> lines is in forming messages to be displayed to a user.
I agree here -- and if it's messages (also comments - a twenty char comment
after a 70 char line should be fine!) then it's not part of the logic of
the code -- so not as bd if there is some spill off the screen for those
folks that do code on tablets ;-) Actually for me, the issue s comes up
when I'm showing code on a projector -- I use a huge font so folks in the
back can see)
> class Frabawidget:
> ...
> @wozzle.setter
> def (self, woozle):
> if not (self.min_woozle < woozle < self.max_woozle):
> raise ValueError(f"Expected woozle to be between
> {self.min_woozle} and {self.max_woozle}")
> self._wozzle = normalize(woozle)
>
That's 103 chars long -- and very readable. But, is this that much worse?
class Frabawidget:
...
@wozzle.setter
def (self, woozle):
if not (self.min_woozle < woozle < self.max_woozle):
raise ValueError(f"Expected woozle to be between"
"{self.min_woozle} and {self.max_woozle}")
self._wozzle = normalize(woozle)
(it IS harder to write, that's for sure)
In doing code reviews, I see many fewer atrocities from long lines than I
> do from weird line-wraps and from variable names that have been
> over-shortened to make the line fit in 80 characters. To avoid these
> issues, my clients typically set their line limits at 90 or 100
and yet the above example was 103 ... you do need a limit somewhere.
I actually would really like the "limit" to depend on what the line is --
that is, it's OK to go longer if it's essentially text -- message to the
user, comment, etc., rather than part of the code logic.
In fact, now that I write that, I think I actually DO do that -- and even
add a # noqa sometimes so my linter will stop bugging me. A smart linter
would be nice here.
PEP 8 is mostly about readability. However, the line length limit often
> seems to cause less readable code.
>
So what do you suggest? simply increase the recommended line length? Or
would softening the language about extending it be enough?
Maybe something along the lines of:
A line length limit should be well defined for each project / organization
-- 80 char per line is safest for all users, but anything up to 100 is
appropriate if the team maintaining the code agrees.
Raymond: As a core dev -- are suggesting extending the line limit for the
standard library?
To all the folks quoting theory: let's be honest. Yes, really long lines
are harder to read, but the 80 char limit comes from old terminals, NOT any
analysis that somehow that is optimum for readability.
-CHB
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
chris.bar...@noaa.gov
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
