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


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

PEP8 79 char max

Started byDevyn Collier Johnson <devyncjohnson@gmail.com>
First post2013-07-29 15:43 -0400
Last post2013-07-31 00:30 -0700
Articles 9 — 7 participants

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


Contents

  PEP8 79 char max Devyn Collier Johnson <devyncjohnson@gmail.com> - 2013-07-29 15:43 -0400
    Re: PEP8 79 char max John Gordon <gordon@panix.com> - 2013-07-29 20:30 +0000
    Re: PEP8 79 char max Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-07-29 21:09 +0000
      Re: PEP8 79 char max "Rhodri James" <rhodri@wildebst.demon.co.uk> - 2013-07-30 00:08 +0100
        Re: PEP8 79 char max Joshua Landau <joshua@landau.ws> - 2013-07-30 01:11 +0100
          Re: PEP8 79 char max "Rhodri James" <rhodri@wildebst.demon.co.uk> - 2013-07-30 01:41 +0100
            Re: PEP8 79 char max Joshua Landau <joshua@landau.ws> - 2013-07-30 03:12 +0100
            Re: PEP8 79 char max Cameron Simpson <cs@zip.com.au> - 2013-07-31 07:32 +1000
    Re: PEP8 79 char max llanitedave <llanitedave@veawb.coop> - 2013-07-31 00:30 -0700

#51481 — PEP8 79 char max

FromDevyn Collier Johnson <devyncjohnson@gmail.com>
Date2013-07-29 15:43 -0400
SubjectPEP8 79 char max
Message-ID<mailman.5257.1375127041.3114.python-list@python.org>
In Python programming, the PEP8 recommends limiting lines to a maximum 
of 79 characters because "There are still many devices around that are 
limited to 80 character lines" 
(http://www.python.org/dev/peps/pep-0008/#code-lay-out). What devices 
cannot handle 80 or more characters on a line? Would following this 
recommendation improve script performance?

Mahalo,

Devyn Collier Johnson
DevynCJohnson@Gmail.com

[toc] | [next] | [standalone]


#51492

FromJohn Gordon <gordon@panix.com>
Date2013-07-29 20:30 +0000
Message-ID<kt6jdu$gv2$1@reader1.panix.com>
In reply to#51481
In <mailman.5257.1375127041.3114.python-list@python.org> Devyn Collier Johnson <devyncjohnson@gmail.com> writes:

> (http://www.python.org/dev/peps/pep-0008/#code-lay-out). What devices 
> cannot handle 80 or more characters on a line?

For a start, older fixed-width dumb terminals and printers.  And even some
very new devices (tablet, smartphone) might have limited screen sizes.

And even if you're on a device that can display more than 80 characters, it
can be convenient to have several windows display side-to-side.

> Would following this recommendation improve script performance?

No, but it improves human readability.

-- 
John Gordon                   A is for Amy, who fell down the stairs
gordon@panix.com              B is for Basil, assaulted by bears
                                -- Edward Gorey, "The Gashlycrumb Tinies"

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


#51497

FromSteven D'Aprano <steve+comp.lang.python@pearwood.info>
Date2013-07-29 21:09 +0000
Message-ID<51f6d9f6$0$30000$c3e8da3$5496439d@news.astraweb.com>
In reply to#51481
On Mon, 29 Jul 2013 15:43:49 -0400, Devyn Collier Johnson wrote:

> In Python programming, the PEP8 recommends limiting lines to a maximum
> of 79 characters because "There are still many devices around that are
> limited to 80 character lines"
> (http://www.python.org/dev/peps/pep-0008/#code-lay-out). What devices
> cannot handle 80 or more characters on a line? 

The only one I can think of is actual xterms (Ctrl-Alt-Function key 
terminals on Unix and Linux). But I think that's actually a red-herring. 
At least for me, I don't care about devices with 80 character lines. 
(Smart phones? Or is that more likely to be 40 character lines?)

I care about being able to put multiple windows side-by-side, or a single 
window with code in one pane and a class map at the side. I care about 
being able to copy and paste code into an email, or Usenet post, without 
it being mangled. I care about *never* having to scroll left-to-right in 
order to read a line.

And most of all, I care about lines being short enough to read without 
eye strain and mental fatigue from excessive horizontal width.


> Would following this
> recommendation improve script performance?

No, it is irrelevant to performance, except performance of the reader.



-- 
Steven

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


#51518

From"Rhodri James" <rhodri@wildebst.demon.co.uk>
Date2013-07-30 00:08 +0100
Message-ID<op.w00ajsxia8ncjz@gnudebeest>
In reply to#51497
On Mon, 29 Jul 2013 22:09:10 +0100, Steven D'Aprano  
<steve+comp.lang.python@pearwood.info> wrote:

> On Mon, 29 Jul 2013 15:43:49 -0400, Devyn Collier Johnson wrote:
>
>> In Python programming, the PEP8 recommends limiting lines to a maximum
>> of 79 characters because "There are still many devices around that are
>> limited to 80 character lines"
>> (http://www.python.org/dev/peps/pep-0008/#code-lay-out). What devices
>> cannot handle 80 or more characters on a line?
>
> The only one I can think of is actual xterms (Ctrl-Alt-Function key
> terminals on Unix and Linux). But I think that's actually a red-herring.
> At least for me, I don't care about devices with 80 character lines.
> (Smart phones? Or is that more likely to be 40 character lines?)
>
> I care about being able to put multiple windows side-by-side, or a single
> window with code in one pane and a class map at the side. I care about
> being able to copy and paste code into an email, or Usenet post, without
> it being mangled. I care about *never* having to scroll left-to-right in
> order to read a line.
>
> And most of all, I care about lines being short enough to read without
> eye strain and mental fatigue from excessive horizontal width.

+1

I'm working on some shonky C code at the moment that inconsistent  
indentation and very long lines.  It is extremely annoying not to be able  
to put the original code, my "translation" and sundry utilities all  
side-by-side on the same screen (and it's not a particularly small  
screen), and having to keep flipping between them slows me down  
dramatically.  Long lines have no effect on the speed of the program, but  
they can have serious effects on the speed of the programmer.

-- 
Rhodri James *-* Wildebeest Herder to the Masses

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


#51530

FromJoshua Landau <joshua@landau.ws>
Date2013-07-30 01:11 +0100
Message-ID<mailman.5295.1375143127.3114.python-list@python.org>
In reply to#51518

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

On 30 July 2013 00:08, Rhodri James <rhodri@wildebst.demon.co.uk> wrote:

> On Mon, 29 Jul 2013 22:09:10 +0100, Steven D'Aprano <
> steve+comp.lang.python@**pearwood.info<steve%2Bcomp.lang.python@pearwood.info>>
> wrote:
>
>  On Mon, 29 Jul 2013 15:43:49 -0400, Devyn Collier Johnson wrote:
>>
>>  In Python programming, the PEP8 recommends limiting lines to a maximum
>>> of 79 characters because "There are still many devices around that are
>>> limited to 80 character lines"
>>> (http://www.python.org/dev/**peps/pep-0008/#code-lay-out<http://www.python.org/dev/peps/pep-0008/#code-lay-out>).
>>> What devices
>>> cannot handle 80 or more characters on a line?
>>>
>>
>> The only one I can think of is actual xterms (Ctrl-Alt-Function key
>> terminals on Unix and Linux). But I think that's actually a red-herring.
>> At least for me, I don't care about devices with 80 character lines.
>> (Smart phones? Or is that more likely to be 40 character lines?)
>>
>> I care about being able to put multiple windows side-by-side, or a single
>> window with code in one pane and a class map at the side. I care about
>> being able to copy and paste code into an email, or Usenet post, without
>> it being mangled. I care about *never* having to scroll left-to-right in
>> order to read a line.
>>
>> And most of all, I care about lines being short enough to read without
>> eye strain and mental fatigue from excessive horizontal width.
>>
>
> +1
>
> I'm working on some shonky C code at the moment that inconsistent
> indentation and very long lines.  It is extremely annoying not to be able
> to put the original code, my "translation" and sundry utilities all
> side-by-side on the same screen (and it's not a particularly small screen),
> and having to keep flipping between them slows me down dramatically.  Long
> lines have no effect on the speed of the program, but they can have serious
> effects on the speed of the programmer.
>

Then just wrap it. This is a very automatable thing for editors. There
might even be a clever hard-wrap somewhere. I just tried pyformat -- that
works wonders.

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


#51533

From"Rhodri James" <rhodri@wildebst.demon.co.uk>
Date2013-07-30 01:41 +0100
Message-ID<op.w00eu0e7a8ncjz@gnudebeest>
In reply to#51530
On Tue, 30 Jul 2013 01:11:18 +0100, Joshua Landau <joshua@landau.ws> wrote:

> On 30 July 2013 00:08, Rhodri James <rhodri@wildebst.demon.co.uk> wrote:
>> I'm working on some shonky C code at the moment that inconsistent
>> indentation and very long lines.  It is extremely annoying not to be  
>> able to put the original code, my "translation" and sundry utilities
>> all side-by-side on the same screen (and it's not a particularly
>> small screen), and having to keep flipping between them slows me
>> down dramatically.   Long lines have no effect on the speed of the
>> program, but they can have serious effects on the speed of the
>> programmer.
>
> Then just wrap it. This is a very automatable thing for editors. There
> might even be a clever hard-wrap somewhere. I just tried pyformat -- that
> works wonders.

I tried that at first, but it actually made matters worse.  "Simple"  
word-wrapping just broke the structural cues from indentation (which I'd  
already had to instruct my editor to make at least somewhat consistent).   
I couldn't just take in the code layout at a glance, I had to work at it.

-- 
Rhodri James *-* Wildebeest Herder to the Masses

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


#51538

FromJoshua Landau <joshua@landau.ws>
Date2013-07-30 03:12 +0100
Message-ID<mailman.5298.1375150398.3114.python-list@python.org>
In reply to#51533

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

On 30 July 2013 01:41, Rhodri James <rhodri@wildebst.demon.co.uk> wrote:

> On Tue, 30 Jul 2013 01:11:18 +0100, Joshua Landau <joshua@landau.ws>
> wrote:
>
>  On 30 July 2013 00:08, Rhodri James <rhodri@wildebst.demon.co.uk> wrote:
>>
>>> I'm working on some shonky C code at the moment that inconsistent
>>> indentation and very long lines.  It is extremely annoying not to be
>>> able to put the original code, my "translation" and sundry utilities
>>> all side-by-side on the same screen (and it's not a particularly
>>> small screen), and having to keep flipping between them slows me
>>> down dramatically.   Long lines have no effect on the speed of the
>>> program, but they can have serious effects on the speed of the
>>> programmer.
>>>
>>
>> Then just wrap it. This is a very automatable thing for editors. There
>> might even be a clever hard-wrap somewhere. I just tried pyformat -- that
>> works wonders.
>>
>
> I tried that at first, but it actually made matters worse.  "Simple"
> word-wrapping just broke the structural cues from indentation (which I'd
> already had to instruct my editor to make at least somewhat consistent).  I
> couldn't just take in the code layout at a glance, I had to work at it.


1) pyformat's quite sane, maybe you should try that. It's a few minutes
wasted at worst. (sudo pip install pyformat; pyformat <infile> [-i for
inplace changes])

2) How does your soft word-wrap work? I know some editors do it terribly,
mine does it passably¹. I don't know any that do it truly semantically
(although it's a feature worthy of implementation).

3) Is the code secret? Let's see a "difficult" snippet if not.

¹ It either indents to the same indentation as the line's start or an extra
indent inwards, depending on context

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


#51609

FromCameron Simpson <cs@zip.com.au>
Date2013-07-31 07:32 +1000
Message-ID<mailman.5344.1375219968.3114.python-list@python.org>
In reply to#51533
On 30Jul2013 01:41, Rhodri James <rhodri@wildebst.demon.co.uk> wrote:
| On Tue, 30 Jul 2013 01:11:18 +0100, Joshua Landau <joshua@landau.ws> wrote:
| >On 30 July 2013 00:08, Rhodri James <rhodri@wildebst.demon.co.uk> wrote:
| >>I'm working on some shonky C code at the moment that inconsistent
| >>indentation and very long lines.
[...]

Have you tried the indent(1) command?

  DESCRIPTION
     indent is a C program formatter.  It reformats the C program in the
     input_file according to the switches.  The switches which can be speci‐
     fied are described below.  They may appear before or after the file
     names.

Very handy sometimes.

Cheers,
-- 
Cameron Simpson <cs@zip.com.au>

The top three answers:  Yes I *am* going to a fire!
                        Oh! We're using *kilometers* per hour now.
                        I have to go that fast to get back to my own time.
- Peter Harper <bo165@FreeNet.Carleton.CA>

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


#51629

Fromllanitedave <llanitedave@veawb.coop>
Date2013-07-31 00:30 -0700
Message-ID<8daf84dc-34d9-4fe1-9819-f388694b706f@googlegroups.com>
In reply to#51481
It's not just the number of characters, it's the size and the font.  Even fixed-width fonts differ greatly in their readability.  

I can handle different line widths just fine up til about 120 or so without losing the flow of the program, but some fonts simply make it more difficult at any width.

I've tried many, but for some reason I keep coming back to Courier10 at 10 points.  I'm almost embarrassed that my choice is such an old and primitive font, but that's how my brain works.

In my experience, if code is well-spaced, well-commented, and broken up into logical groups with appropriate blank spaces, line length can be about 3/4 the width of whatever editor is being used.  And most editors are wide enough to easily accommodate over 100 characters.

[toc] | [prev] | [standalone]


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


csiph-web