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@python.org> wrote:
Send Python-ideas mailing list submissions to
python-ideas@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@python.org
You can reach the person managing the list at
python-ideas-owner@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@gmail.com>
To: Mike Miller <python-ideas@mgmiller.net>
Cc: "python-ideas@python.org" <python-ideas@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@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@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@noaa.gov>
To: Python-Ideas <python-ideas@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@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@noaa.gov
---------- Forwarded message ----------
From: "Juancarlo Añez" <apalala@gmail.com>
To: Ivan Levkivskyi <levkivskyi@gmail.com>
Cc: Miikka Salminen <miikka.salminen@gmail.com>, python-ideas <
python-ideas@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@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@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*
Philip Bergen