On 2019-02-20 18:41, Christopher Barker wrote:
God no! I HATE that style -- for me, it makes it MUCH harder to read --
even more so if the variable names are a bit longer.
But if you are going to do it, for the love of god, use more than four
spaces! four spaces is one indentation, one indentation is how a code
block is delineated in Python -- this is NOT a code block. It should not
look like one.
I feel the complete opposite. "One indentation" is the only unit in
multiples of which anything should ever be indented. Using arbitrary
"indentation" to visually line things up is horrible. Everything gets
indented by an integer number of indentation levels.
It was mentioned earlier on this thread, but I think the real problem
is editors. Specifically, people have become used to certain editor
behaviors and conventions which are not actually that great, and as a
result editors have not emphasized features which would be better. Even
more specifically, people have not insisted that editors be designed to
support a reader-oriented, rather than writer-oriented, approach to code
display. In other words, visual details how the code is displayed
should be up to person reading the code, not the person who wrote it.
Instead, people have apparently for a long time insisted on the
reverse, namely editors which format things as the code is written, by
inserting actual characters in the file to make things like up visually.
Characters shouldn't be in the file to make things like up visually;
they should be there for their semantic importance. If that is done,
then the editor can render those semantics in different ways according
to the viewer's preference.
The problem is that editors don't do this, because people have somehow
gotten the idea that this would be a bad thing. So instead we have to
argue over things like this, because whatever purely cosmetic choices
one person makes in indenting his or her code become baked into the
actual bytes of the file, and cannot be rendered differently later
according to the preferences of a different viewer.
I've rather forlornly given up on dealing with any of this. I use an
editor that VISUALLY wraps long lines and maintains the indentation on
the wrapped portion, without changing the bytes in the file. I make my
lines as long as I want, inserting linebreaks only where they have a
semantic reason to be (such as between multiple long conditions in an
"if"). Everything is fine, until someone else looks at the code, and
they have an editor that is only designed to display code that has the
formatting baked into the whitespace.
As a result, I consider this issue pretty much moot. There is no
reason for the line length limit to be set to 100 or 120 or anything
else. There are already too many problems with PEP 8 that stem from a
desire to use whitespace for visual alignment rather than semantics
(such as using spaces instead of tabs). So I just basically ignore PEP
8 and follow my own style, which happens to overlap in some respects
with PEP 8 and diverge from it in others.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
