[Python-ideas] PEP 8 update on line length
Philip Bergen
pbergen at salesforce.com
Fri Feb 22 02:38:22 EST 2019
I agree that 80 columns produces too much artificial wrapping that is not
more readable and harder to maintain. To that point see the bug in Chris
Barker's email :)
raise ValueError(f"Expected woozle to be between"
"{self.min_woozle} and {self.max_woozle}")
The missing f prefix on the second row is hard to spot.
In my work we have settled on 100 characters. It's below the practical
limitation where code review tools such as github pull request falls apart
and still easily allows side by side editing.
On Thu, Feb 21, 2019 at 3:20 PM <python-ideas-request at python.org> wrote:
> Send Python-ideas mailing list submissions to
> python-ideas at python.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mail.python.org/mailman/listinfo/python-ideas
> or, via email, send a message with subject or body 'help' to
> python-ideas-request at python.org
>
> You can reach the person managing the list at
> python-ideas-owner at python.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Python-ideas digest..."
> Today's Topics:
>
> 1. Re: PEP 8 update on line length (pylang)
> 2. Re: PEP 8 update on line length (Chris Barker)
> 3. Re: Type hints for functions with side-effects and for
> functions raising exceptions (Juancarlo A?ez)
>
>
>
> ---------- Forwarded message ----------
> From: pylang <pylang3 at gmail.com>
> To: Mike Miller <python-ideas at mgmiller.net>
> Cc: "python-ideas at python.org" <python-ideas at python.org>
> Bcc:
> Date: Thu, 21 Feb 2019 17:32:12 -0500
> Subject: Re: [Python-ideas] PEP 8 update on line length
> Some feedback:
>
> I code on a 13.5 inch laptop. I split my screen between my browser on the
> left half and editor on the right half of the screen.
> The 80 character suggestion has been helpful to me in reading code.
> Otherwise I'd use up time with random horizontal scrolling.
>
> On Thu, Feb 21, 2019 at 4:11 PM Mike Miller <python-ideas at mgmiller.net>
> wrote:
>
>>
>> On 2/21/19 10:53 AM, Paul Ferrell wrote:
>> > I think the solution is for everyone to rotate their widescreen
>> monitors 90°
>> > into a really tall portrait mode. :)
>>
>> Yep, that's what I do, but would prefer a squarer monitor so I could get
>> two
>> windows side by side on that one also. My old 1600x1200 4:3 in portrait
>> allowed
>> that comfortably. 16:10 might.
>>
>> -Mike
>>
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
>
> ---------- Forwarded message ----------
> From: Chris Barker <chris.barker at noaa.gov>
> To: Python-Ideas <python-ideas at python.org>
> Cc:
> Bcc:
> Date: Thu, 21 Feb 2019 17:06:51 -0800
> Subject: Re: [Python-ideas] PEP 8 update on line length
> On Thu, Feb 21, 2019 at 12:01 PM Raymond Hettinger <
> raymond.hettinger at 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.Barker at noaa.gov
>
>
>
> ---------- Forwarded message ----------
> From: "Juancarlo Añez" <apalala at gmail.com>
> To: Ivan Levkivskyi <levkivskyi at gmail.com>
> Cc: Miikka Salminen <miikka.salminen at gmail.com>, python-ideas <
> python-ideas at python.org>
> Bcc:
> Date: Thu, 21 Feb 2019 21:20:38 -0400
> Subject: Re: [Python-ideas] Type hints for functions with side-effects and
> for functions raising exceptions
>
>
> On Thu, Feb 21, 2019 at 6:28 PM Ivan Levkivskyi <levkivskyi at gmail.com>
> wrote:
>
>> The idea about "checked exceptions" appeared several times in various
>> places. I used to think that this would be hard to support for any
>> realistic use cases. But now I think there may be a chance
>> to turn this into a usable feature if one frames it correctly (e.g. the
>> focus could be on user defined exceptions, rather than on standard ones,
>> since there is no way we can annotate every function in typeshed).
>>
>
> It's well documented how checked exceptions lead to bad code. That's why
> C#, which came after Java, didn't include them.
>
> Exceptions may be logically thought as of part of the type of a method,
> and of the type of the method's class, but that requires that the type
> catches every exception that may be raised from the implementation and
> either handles it, or translates it to one belonging to the type. It's a
> lot of work, it's cumbersome, and it is fragile, as the exception handling
> may need to change over minor implementation changes. If dependencies don't
> treat the exceptions that may escape from them as part of the type, then
> our own types will need to be changes every time a dependency changes its
> implementation.
>
> The strategy of catching only exceptions of interest and letting others
> pass produces less fragile and easier to test code.
>
> --
> Juancarlo *Añez*
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
>
--
*Philip Bergen*
P: +1(415)200-7340
*"Without data you are just another person with an opinion" -- W. Edwards
Deming*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20190221/dcf995f5/attachment-0001.html>
More information about the Python-ideas
mailing list