PEP 8 : Maximum line Length :

[Rustom Mody]

Rather, I've claimed that the conventional lime length limit is *based
in* the real cognitive limits of human reading comprehension -- and that
technologies have been designed with corresponding limitations.


Nowhere have I claimed 79 or 80 are somehow fundamental or encoded in
human cognition, and I have seen no-one else claim that. Please try to
work within your own cognitive limits and read what people write for
comprehension.

You said this:

The 80 character line limit is *not* driven by a limitation of computer
technology; it is driven by a limitation of human cognition. For that
reason, it remains relevant until human cognition in the general reading
population improves.

And you answered:

 

[Steven D'Aprano]

A definitive Python source file could be binary, XML, .py, .ast,
whatever,

Containing *what*? You can't just wave your hands and say "binary". What
sort of binary file? Perhaps a JPEG file, where red triangles of
different sizes represent keywords. Variable names can be encoded using a
pattern of purple dots. Expressions and blocks of code can be formed by
joining components with lines. Operators by squares of different colours
(green means +, blue means -, etc.).

No? Then what?

Besides, where does the information inside the file come from? You surely
don't expect people to write the binary data/AST/whatever directly. How
can the zip file be "definitive" when it is derived from something more
fundamental?

Source code is, *by definition*, the definitive version. (It's the
SOURCE, see?) Zipping the source code just means that the *source* inside
the zip file is the definitive version, not the compressed binary data.

The AST is not definitive. Human beings write *text*, which is what the
source code is. It may be text with an especially restrictive grammar,
but it's still text. Everything else -- the parse tree, the abstract
syntax tree, the byte code, the machine code, the compressed text,
encrypted text, the pixel rendering of the text, ... are derived from the
code as written by human beings.

Code is written primarily for human beings. Many programmers, and many
language designers, don't realise this, which is why so many programs are
write-only code. Presentation *is important*, and cannot always be
separated from semantics without hurting the primary audience, the human
reader. This is what code obfuscators do, deliberately: mangle the
presentation while keeping the semantics the same. You're inadvertently
proposing the same thing (albeit to a lesser degree).

 

[Steven D'Aprano]

The claim being made is that 79/80 is a fundamental, cognitive limit and
has no relation to technological changes.

I don't believe anyone has made that claim. You are reading a statement
about general (typical, average) behaviour, and turning it into an absurd
statement of a "fundamental" (your word) which applies to every single
human being on earth.

 

[Chris Angelico]

Containing *what*? You can't just wave your hands and say "binary". What
sort of binary file? Perhaps a JPEG file, where red triangles of
different sizes represent keywords. Variable names can be encoded using a
pattern of purple dots. Expressions and blocks of code can be formed by
joining components with lines. Operators by squares of different colours
(green means +, blue means -, etc.).

http://www.dangermouse.net/esoteric/piet.html

ChrisA

 

[Chris Angelico]

Well, actually, any .py file *does* specify a unique AST. Nothing would
prevent the text editor from presenting it according to your
preferences. They all do that to a degree anyway (colors, fonts), but
they could take even more liberties (which some IDE's do: hiding/showing
comments and function definitions).

There are tools that reindent and refactor code automatically. The text
editor could do that on the fly.

You still haven't answered my biggest objection from earlier. Source
code contains more information than the AST does; even if you make a
frAnkenSTein's monster that includes comments, there's still the point
that whitespace carries information, and that information is
frequently communicative of the programmer's intent. Any automated
reformatter destroys that information, and that is, by definition, a
net loss to the code. How do you propose to fix that? Or if not, will
you at least acknowledge that the AST cannot perfectly transmit what
the source code says?

ChrisA

 

[Marko Rauhamaa]

You still haven't answered my biggest objection from earlier. Source
code contains more information than the AST does; even if you make a
frAnkenSTein's monster that includes comments, there's still the point
that whitespace carries information, and that information is
frequently communicative of the programmer's intent. Any automated
reformatter destroys that information, and that is, by definition, a
net loss to the code. How do you propose to fix that? Or if not, will
you at least acknowledge that the AST cannot perfectly transmit what
the source code says?

If every bit of your Python text conveys information, obviously, it
can't be abstracted. I don't believe that to be the case, though. So
this AST should contain all *actual* information worth conveying and
strip away irrelevant stuff.

Examples:

* Function definition order.

* Indentation depth.

* Vertical empty space.


Of course, I'm not being completely serious about all this stuff because
the surface coding style questions are among the least relevant problems
in the code. But at least that kind of arrangement would free us from
the heated debates concerning the maximum line length etc.

(BTW, regardless of PEP8, the maximum line length *must* be 79, and the
maximum function length *must* be whatever can be seen on the screen at
once.)


Marko

 

[Chris Angelico]

If every bit of your Python text conveys information, obviously, it
can't be abstracted. I don't believe that to be the case, though. So
this AST should contain all *actual* information worth conveying and
strip away irrelevant stuff.

Examples:

* Function definition order.

* Indentation depth.

* Vertical empty space.

* Logical layout as expressed by whitespace and specific line breaks.

Compare these two assignment statements:

area = (base*base + extension*extension
+ annex*annex + (annex-extension)*annex
+ triangle*triangle/2
+ circle*circle*math.PI + sphere*sphere*4*math.PI)

area = (base*base + extension*extension + annex*annex
+ (annex-extension)*annex + triangle*triangle/2
+ circle*circle*math.PI + sphere*sphere*4*math.PI)

Both are wrapped to sixty characters, which means they can be indented
twenty without breaking PEP 8. One of them takes up only three lines,
the other takes up four. But the first one groups the annex's terms,
separates out the triangle, groups the circular elements, and
presumably corresponds accurately to the (mythical) real-world
geometry that it's implementing. How are you going to cope with this
distinction? That's real, useful information, which the AST doesn't
carry.

(You might argue that each of these lines should have a comment at the
end of it or above it, which would provide that grouping. But in that
case, you lose the canonicalization of anything with trailing comments
or interspersed comments, meaning that you effectively can't reformat
anything with comments in it.)

ChrisA

 

[Marko Rauhamaa]

Compare these two assignment statements:

area = (base*base + extension*extension
+ annex*annex + (annex-extension)*annex
+ triangle*triangle/2
+ circle*circle*math.PI + sphere*sphere*4*math.PI)

area = (base*base + extension*extension + annex*annex
+ (annex-extension)*annex + triangle*triangle/2
+ circle*circle*math.PI + sphere*sphere*4*math.PI)

[...]
How are you going to cope with this distinction? That's real, useful
information, which the AST doesn't carry.

Such nuances would be lost, yes. However, the nuances are constantly
abused and misinterpreted anyway.


Marko