Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #51761 > unrolled thread

PEP8 revised: max line lengths

Back to article view | Back to comp.lang.python

Contents

  PEP8 revised: max line lengths Terry Reedy <tjreedy@udel.edu> - 2013-08-01 15:52 -0400
    Re: PEP8 revised: max line lengths Roy Smith <roy@panix.com> - 2013-08-01 20:51 -0400
      Re: PEP8 revised: max line lengths Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-08-02 04:28 +0000
      Re: PEP8 revised: max line lengths Chris “Kwpolska” Warrick <kwpolska@gmail.com> - 2013-08-02 13:07 +0200
        Re: PEP8 revised: max line lengths wxjmfauth@gmail.com - 2013-08-02 08:08 -0700
          Re: PEP8 revised: max line lengths Skip Montanaro <skip@pobox.com> - 2013-08-02 10:19 -0500
            Re: PEP8 revised: max line lengths wxjmfauth@gmail.com - 2013-08-02 14:15 -0700
              Re: PEP8 revised: max line lengths Chris Angelico <rosuav@gmail.com> - 2013-08-02 22:34 +0100
              Re: PEP8 revised: max line lengths Joshua Landau <joshua@landau.ws> - 2013-08-03 03:21 +0100
              Re: PEP8 revised: max line lengths Chris Angelico <rosuav@gmail.com> - 2013-08-03 07:43 +0100
                Re: PEP8 revised: max line lengths Roy Smith <roy@panix.com> - 2013-08-03 11:00 -0400
                  Re: PEP8 revised: max line lengths wxjmfauth@gmail.com - 2013-08-03 10:21 -0700
      Re: PEP8 revised: max line lengths Nicholas Cole <nicholas.cole@gmail.com> - 2013-08-03 12:35 +0100
        Re: PEP8 revised: max line lengths wxjmfauth@gmail.com - 2013-08-04 02:52 -0700
          Re: PEP8 revised: max line lengths Roy Smith <roy@panix.com> - 2013-08-04 10:07 -0400
            Re: PEP8 revised: max line lengths Sergi Pasoev <s.pasoev@gmail.com> - 2013-08-04 18:20 +0400
            Re: PEP8 revised: max line lengths Sergi Pasoev <s.pasoev@gmail.com> - 2013-08-04 18:27 +0400
            Re: PEP8 revised: max line lengths Chris Angelico <rosuav@gmail.com> - 2013-08-04 15:18 +0100
              Re: PEP8 revised: max line lengths Roy Smith <roy@panix.com> - 2013-08-04 14:18 -0400
                Re: PEP8 revised: max line lengths Chris Angelico <rosuav@gmail.com> - 2013-08-04 19:23 +0100

#51761 — PEP8 revised: max line lengths

Newly revised this morning:
http://www.python.org/dev/peps/pep-0008/#maximum-line-length
summary:
72 for text block (comments, triple-quoted strings)
79 for normal code
99 for code that is really more readable with extra

The diff with all the changes is here
http://hg.python.org/peps/rev/fb24c80e9afb
-- 
Terry Jan Reedy

[toc] | [next] | [standalone]

#51774

In article <mailman.93.1375386763.1251.python-list@python.org>,
 Terry Reedy <tjreedy@udel.edu> wrote:

> Newly revised this morning:
> http://www.python.org/dev/peps/pep-0008/#maximum-line-length
> summary:
> 72 for text block (comments, triple-quoted strings)
> 79 for normal code
> 99 for code that is really more readable with extra

And the people did rejoice and did feast upon the lambs and toads and 
tree-sloths and fruit-bats and orangutans and breakfast cereals.

[toc] | [prev] | [next] | [standalone]

#51781

On Thu, 01 Aug 2013 20:51:43 -0400, Roy Smith wrote:

> In article <mailman.93.1375386763.1251.python-list@python.org>,
>  Terry Reedy <tjreedy@udel.edu> wrote:
> 
>> Newly revised this morning:
>> http://www.python.org/dev/peps/pep-0008/#maximum-line-length summary:
>> 72 for text block (comments, triple-quoted strings) 79 for normal code
>> 99 for code that is really more readable with extra
> 
> And the people did rejoice and did feast upon the lambs and toads and
> tree-sloths and fruit-bats and orangutans and breakfast cereals.

Except on Python-Dev, where feedback on allowing longer lines is almost 
entirely negative. The consensus seems to be, if you have a line of code 
that is more than 79 characters, and less than 100 characters, and there 
is no clean way to break it over multiple lines, then it is acceptable to 
not break it.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#51794

On Fri, Aug 2, 2013 at 2:51 AM, Roy Smith <roy@panix.com> wrote:
> In article <mailman.93.1375386763.1251.python-list@python.org>,
>  Terry Reedy <tjreedy@udel.edu> wrote:
>
>> Newly revised this morning:
>> http://www.python.org/dev/peps/pep-0008/#maximum-line-length
>> summary:
>> 72 for text block (comments, triple-quoted strings)
>> 79 for normal code
>> 99 for code that is really more readable with extra
>
> And the people did rejoice and did feast upon the lambs and toads and
> tree-sloths and fruit-bats and orangutans and breakfast cereals.

The 99-characters rule does not apply for the stdlib.  And outside of
the stdlib, PEP 8 is not mandated by Python (but it might be by the
project leader or similar entities).  If someone wanted long lines,
then they could do so ALL THE TIME.

So, what are you feasting for?  Nothing?

-- 
Chris “Kwpolska” Warrick <http://kwpolska.tk>
PGP: 5EAAEA16
stop html mail | always bottom-post | only UTF-8 makes sense

[toc] | [prev] | [next] | [standalone]

#51816

Le vendredi 2 août 2013 13:07:47 UTC+2, Chris “Kwpolska” Warrick a écrit :
> On Fri, Aug 2, 2013 at 2:51 AM, Roy Smith <roy@panix.com> wrote:
> 
> > In article <mailman.93.1375386763.1251.python-list@python.org>,
> 
> >  Terry Reedy <tjreedy@udel.edu> wrote:
> 
> >
> 
> >> Newly revised this morning:
> 
> >> http://www.python.org/dev/peps/pep-0008/#maximum-line-length
> 
> >> summary:
> 
> >> 72 for text block (comments, triple-quoted strings)
> 
> >> 79 for normal code
> 
> >> 99 for code that is really more readable with extra
> 
> >
> 
> > And the people did rejoice and did feast upon the lambs and toads and
> 
> > tree-sloths and fruit-bats and orangutans and breakfast cereals.
> 
> 
> 
> The 99-characters rule does not apply for the stdlib.  And outside of
> 
> the stdlib, PEP 8 is not mandated by Python (but it might be by the
> 
> project leader or similar entities).  If someone wanted long lines,
> 
> then they could do so ALL THE TIME.
> 
> 
> 
> So, what are you feasting for?  Nothing?
> 
> 
> 
> -- 
> 
> Chris “Kwpolska” Warrick <http://kwpolska.tk>
> 
> PGP: 5EAAEA16
> 
> stop html mail | always bottom-post | only UTF-8 makes sense

And do not forget, a monospaced font is never monospaced
(for understandable reasons).
The solely valid solution, assuming there is some wish,
is to define a maximal line width (preferably in SI units ;-)

The day, the devs succeed to think non ascii, is not
arrived.

jmf

PS independently of the CJK stuff.

[toc] | [prev] | [next] | [standalone]

#51819

> The solely valid solution, assuming there is some wish,
> is to define a maximal line width (preferably in SI units ;-)

So, 79 * 8 points == 0.222955555696 meters, right? :-)

Skip

[toc] | [prev] | [next] | [standalone]

#51823

Le vendredi 2 août 2013 17:19:11 UTC+2, Skip Montanaro a écrit :
> > The solely valid solution, assuming there is some wish,
> 
> > is to define a maximal line width (preferably in SI units ;-)
> 
> 
> 
> So, 79 * 8 points == 0.222955555696 meters, right? :-)
> 
> 
> 
> Skip

You can correct your mistake yourself. In your
equation, the unit at the left is [1] * [point] = [point],
at the right the unit is [meter], obviously
[point] != [meter].


Problem #1
For a tool which is supposed to be Unicode compliant,
a Unicode compliant font has never a constant pitch,
so counting a maximal width in number of characters
does not make sense.

Problem #2
The only valid constraint which makes sense is
a maximal size in a length unit. Two possibilities:
– if you consider your document is to be viewed
as a screen document, pixel comes in mind.
– if you condider your document will be printed,
retain a physical unit length (cm, inch).

Problem #3
cm or inch? The only serious unit is an SI unit.
(In scientific publications, only SI units are accepted)


Hint: Put you code in a pdf.

jmf

[toc] | [prev] | [next] | [standalone]

#51824

On Fri, Aug 2, 2013 at 10:15 PM,  <wxjmfauth@gmail.com> wrote:
> Le vendredi 2 août 2013 17:19:11 UTC+2, Skip Montanaro a écrit :
>> > The solely valid solution, assuming there is some wish,
>> > is to define a maximal line width (preferably in SI units ;-)
>>
>> So, 79 * 8 points == 0.222955555696 meters, right? :-)
>>
>> Skip
>
> You can correct your mistake yourself. In your
> equation, the unit at the left is [1] * [point] = [point],
> at the right the unit is [meter], obviously
> [point] != [meter].

http://en.wikipedia.org/wiki/Point_(typography)

A point is one twelfth of a pica, which is one sixth of an inch, which
is 0.0254 SI millimeters. Do the arithmetic. Skip is absolutely
correct.

> Problem #1
> For a tool which is supposed to be Unicode compliant,
> a Unicode compliant font has never a constant pitch,
> so counting a maximal width in number of characters
> does not make sense.
>
> Problem #2
> The only valid constraint which makes sense is
> a maximal size in a length unit. Two possibilities:
> – if you consider your document is to be viewed
> as a screen document, pixel comes in mind.
> – if you condider your document will be printed,
> retain a physical unit length (cm, inch).
>
> Problem #3
> cm or inch? The only serious unit is an SI unit.
> (In scientific publications, only SI units are accepted)

The cm is not a primary SI unit either.

> Hint: Put you code in a pdf.

Hint: Put your code in a bitmap for screens *and* a PDF for printing.
That's the only way to guarantee that it'll work.

Since this is not possible, there is one solution left: Do not view
your code on screen, but only print it out. Then you can guarantee
that your columns are as you expected. Python could be enhanced to
take advantage of this; for instance, instead of requiring the hash
character (which may be difficult to type on certain keyboards,
including mobile phones), a letter C (U+0043) in column 1 can cause
the line to be considered a Comment.

ChrisA

[toc] | [prev] | [next] | [standalone]

#51840

[Multipart message — attachments visible in raw view] — view raw

On 2 August 2013 22:34, Chris Angelico <rosuav@gmail.com> wrote:

> On Fri, Aug 2, 2013 at 10:15 PM,  <wxjmfauth@gmail.com> wrote:
>
 > Problem #3
> > cm or inch? The only serious unit is an SI unit.
> > (In scientific publications, only SI units are accepted)
>
> The cm is not a primary SI unit either.


But it is an SI unit.

(As a side note, humorously when watching University Challenge today one of
the semi-finalist teams were unable to convert degrees fahrenheit to
celsius. This just goes to show that non-SI units are e̶v̶i̶l̶ hard.)


> > Hint: Put you code in a pdf.
>
> Hint: Put your code in a bitmap for screens *and* a PDF for printing.
> That's the only way to guarantee that it'll work.
>
> Since this is not possible, there is one solution left: Do not view
> your code on screen, but only print it out. Then you can guarantee
> that your columns are as you expected. Python could be enhanced to
> take advantage of this; for instance, instead of requiring the hash
> character (which may be difficult to type on certain keyboards,
> including mobile phones), a letter C (U+0043) in column 1 can cause
> the line to be considered a Comment.
>

This is jmf. It'd have to be a Euro.

[toc] | [prev] | [next] | [standalone]

#51861

On Sat, Aug 3, 2013 at 3:21 AM, Joshua Landau <joshua@landau.ws> wrote:
> On 2 August 2013 22:34, Chris Angelico <rosuav@gmail.com> wrote:
>>
>> On Fri, Aug 2, 2013 at 10:15 PM,  <wxjmfauth@gmail.com> wrote:
>>
>> > Problem #3
>> > cm or inch? The only serious unit is an SI unit.
>> > (In scientific publications, only SI units are accepted)
>>
>> The cm is not a primary SI unit either.
>
>
> But it is an SI unit.

Sorry. Term I should have used is "base SI unit". Instead of using the
cm, use the m. Or go three orders of magnitude at a time to the km or
the mm.

ChrisA

[toc] | [prev] | [next] | [standalone]

#51864

In article <mailman.158.1375541014.1251.python-list@python.org>,
 Chris Angelico <rosuav@gmail.com> wrote:

> Sorry. Term I should have used is "base SI unit". Instead of using the
> cm, use the m. Or go three orders of magnitude at a time to the km or
> the mm.

Or, go digital, and use Kim (kibimeters).

[toc] | [prev] | [next] | [standalone]

#51871

------

I do not care about this limit. It is however
an interesting point regarding Unicode.

Setting a limit with the help of number of chars
is a non sense.

Eg. this chess board with a monospace "Unicode font"
(Consolas).

>>> print("""
... |♖|♘|♗|♕|♔|♗|♘|♖|
... |♙|♙|♙|♙|♙|♙|♙|＿|
... |＿|＿|＿|＿|＿|＿|＿|＿|
... |＿|＿|＿|＿|＿|＿|＿|♙|
... |＿|＿|＿|＿|＿|＿|＿|＿|
... |＿|＿|＿|＿|＿|＿|＿|＿|
... |♟|♟|♟|♟|♟|♟|♟|♟|
... |♜|♞|♝|♛|♚|♝|♞|♜|
... 12345678901234567
... """)

|♖|♘|♗|♕|♔|♗|♘|♖|
|♙|♙|♙|♙|♙|♙|♙|＿|
|＿|＿|＿|＿|＿|＿|＿|＿|
|＿|＿|＿|＿|＿|＿|＿|♙|
|＿|＿|＿|＿|＿|＿|＿|＿|
|＿|＿|＿|＿|＿|＿|＿|＿|
|♟|♟|♟|♟|♟|♟|♟|♟|
|♜|♞|♝|♛|♚|♝|♞|♜|
12345678901234567


The old limit (79) had a sense because at that
time, the "technology" was consistent, editor, screen,
printer.
Today, this is no more the case. Setting a limit of
99 in the spirit of the old 79 just become impossible.

Of course, it is still possible to give *recommendations*,
but creating a *rule* just becomes impossible.


The byte string world and the Unicode world are
two incompatilble worlds. Working with unicode
implies a different way of thinking (not only
on the side of the coding of characters).

jmf

[toc] | [prev] | [next] | [standalone]

#51862

[Multipart message — attachments visible in raw view] — view raw

On Friday, 2 August 2013, Chris “Kwpolska” Warrick wrote:

[snip]

>
> So, what are you feasting for?  Nothing?


I have long since ceased to be amazed at the number of people who would
like their personal and arbitrary preferences, and the rationalisations
that go with them, to be validated and endorsed by others, in law if
possible and in policy documents if not!

[toc] | [prev] | [next] | [standalone]

#51915

Le samedi 3 août 2013 13:35:29 UTC+2, Nicholas a écrit :
> On Friday, 2 August 2013, Chris “Kwpolska” Warrick  wrote:
> 
> 
> [snip]
> 
> 
> 
> So, what are you feasting for?  Nothing?
> 
> 
> I have long since ceased to be amazed at the number of people who would like their personal and arbitrary preferences, and the rationalisations that go with them, to be validated and endorsed by others, in law if possible and in policy documents if not!

----------

I have always found, computer scientists are funny scientists.


- They do love to solve the problems, they created themselves.

- They have the tendency to take the consequences as
the causalities.

- And they forget:

i)    p  => q   <==>   not(q) => not(p)

ii)   To proof a law is correct, one has to proof it's correct
in all cases. To proof a law is incorrect, it is enough to
find one, and solelely one, case showing the law is incorrect.


In my computing experience, the "Python world" is really shining
on these points.

jmf

[toc] | [prev] | [next] | [standalone]

#51920

In article <d2e561f1-f5ba-4242-941d-6989abd1a482@googlegroups.com>,
 wxjmfauth@gmail.com wrote:

> I have always found, computer scientists are funny scientists.

I have always found that sciences which contain the word "science" in 
their name tend to not be very scientific.

Biology, Chemistry, Physics, those are real sciences.  Computer Science, 
Social Science, Political Science, not so much.

[toc] | [prev] | [next] | [standalone]

#51921

Let's say computer science isn't science. 

[toc] | [prev] | [next] | [standalone]

#51922

What about Earth Science? But in this case, it is indeed science,
because in its name the word science is applied to the object of its
study. But in the case of "computer science", the word science is
applied to the word which describes the tool this "science" uses!! It's
like it was Telescope Science in the name of astronomy. 

[toc] | [prev] | [next] | [standalone]

#51931

On Sun, Aug 4, 2013 at 3:07 PM, Roy Smith <roy@panix.com> wrote:
> In article <d2e561f1-f5ba-4242-941d-6989abd1a482@googlegroups.com>,
>  wxjmfauth@gmail.com wrote:
>
>> I have always found, computer scientists are funny scientists.
>
> I have always found that sciences which contain the word "science" in
> their name tend to not be very scientific.
>
> Biology, Chemistry, Physics, those are real sciences.  Computer Science,
> Social Science, Political Science, not so much.

Right. We use the scientific method only in our worst work, like
poking at a black-box system to try to reverse compile it. Our work
generally involves examining a problem and figuring out which set of
tools will best solve it, which is more of an engineering thing.
("Build a bridge. Your chasm is X meters across, your bridge must
support Y kg of vehicles traversing it, the terrain is unsuited to
pylons, and you must not exceed Z meters of height above the road
surface.") And programmers, like engineers, have to deal with the
possibility (or certainty) of idiots using their products. This is not
a pure science by any means.

ChrisA

[toc] | [prev] | [next] | [standalone]

#51932

In article <mailman.186.1375639877.1251.python-list@python.org>,
 Chris Angelico <rosuav@gmail.com> wrote:

> programmers, like engineers, have to deal with the
> possibility (or certainty) of idiots using their products.

As a programmer, I'm OK with the idea that idiots are using my programs.  
What bothers me more is when, as a user of a program, I have to deal 
with the fact that idiots wrote it.

[toc] | [prev] | [next] | [standalone]

#51935

On Sun, Aug 4, 2013 at 7:18 PM, Roy Smith <roy@panix.com> wrote:
> In article <mailman.186.1375639877.1251.python-list@python.org>,
>  Chris Angelico <rosuav@gmail.com> wrote:
>
>> programmers, like engineers, have to deal with the
>> possibility (or certainty) of idiots using their products.
>
> As a programmer, I'm OK with the idea that idiots are using my programs.
> What bothers me more is when, as a user of a program, I have to deal
> with the fact that idiots wrote it.

Heh. Yeah. Too true.

ChrisA

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web