Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Re: PEP8 79 char max

Reply
Thread Tools

Re: PEP8 79 char max

 
 
Devyn Collier Johnson
Guest
Posts: n/a
 
      07-29-2013

On 07/29/2013 04:08 PM, Joel Goldstick wrote:
> On Mon, Jul 29, 2013 at 3:43 PM, Devyn Collier Johnson
> <(E-Mail Removed)> 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?

> well, punch cards
> Would following
>> this recommendation improve script performance?

> Not performance, but human readability
>> Mahalo,
>>
>> Devyn Collier Johnson
>> http://www.velocityreviews.com/forums/(E-Mail Removed)
>> --
>> http://mail.python.org/mailman/listinfo/python-list

>
>

So, I can have a script with large lines and not negatively influence
performance on systems that do not use punch cards?

DCJ
 
Reply With Quote
 
 
 
 
Steven D'Aprano
Guest
Posts: n/a
 
      07-29-2013
On Mon, 29 Jul 2013 16:24:51 -0400, Devyn Collier Johnson wrote:

> So, I can have a script with large lines and not negatively influence
> performance on systems that do not use punch cards?


You'll negatively influence anyone who has to read, or edit, your code.
Very likely including you.

But no, there's no meaningful performance difference based on line
length. Interpreting the source code is not meaningfully affected by line
length, and by the time the code is compiled and then run, line length is
irrelevant.



--
Steven
 
Reply With Quote
 
 
 
 
Devyn Collier Johnson
Guest
Posts: n/a
 
      07-29-2013

On 07/29/2013 05:42 PM, Steven D'Aprano wrote:
> On Mon, 29 Jul 2013 16:24:51 -0400, Devyn Collier Johnson wrote:
>
>> So, I can have a script with large lines and not negatively influence
>> performance on systems that do not use punch cards?

> You'll negatively influence anyone who has to read, or edit, your code.
> Very likely including you.
>
> But no, there's no meaningful performance difference based on line
> length. Interpreting the source code is not meaningfully affected by line
> length, and by the time the code is compiled and then run, line length is
> irrelevant.
>
>
>

Evidently, it is personal preference. I prefer to read computer code
like a book (yes, I am a weirdo (^u^)). The only time I exced 79
characters is when I write a set of commands that perform similar tasks.
I do not make too many lines over 79 char. Thanks everyone for the
comments and feedback.

Mahalo,

DCJ
 
Reply With Quote
 
Ed Leafe
Guest
Posts: n/a
 
      07-29-2013
On Jul 29, 2013, at 5:30 PM, Devyn Collier Johnson <(E-Mail Removed)> wrote:

> Evidently, it is personal preference. I prefer to read computer code like a book (yes, I am a weirdo (^u^)). The only time I exced 79 characters is when I write a set of commands that perform similar tasks. I do not make too many lines over 79 char. Thanks everyone for the comments and feedback.


I have heard this statement before, and so I'm wondering: do you read books printed in monospaced typefaces, or do they have proportional fonts? I've yet to come across anything meant to be read as literature that was monospaced, because it is much harder to read.

I had read about a developer who switched to using proportional fonts for coding, and somewhat skeptically, tried it out. After a day or so it stopped looking strange, and after a week it seemed so much easier to read. I only switched back because I found I lost productivity switching from vim to a graphical text editor.


-- Ed Leafe





 
Reply With Quote
 
Vito De Tullio
Guest
Posts: n/a
 
      07-30-2013
Ed Leafe wrote:

> I had read about a developer who switched to using proportional fonts for
> coding, and somewhat skeptically, tried it out. After a day or so it
> stopped looking strange, and after a week it seemed so much easier to
> read.


By my (limited) experience with proportional fonts, they can be useful only
with something like elastic tabstops[0]. But, as a general rule, I simply
found more "squared" to just use a fixed-width font.


[0] http://nickgravgaard.com/elastictabstops/

--
ZeD

 
Reply With Quote
 
Joshua Landau
Guest
Posts: n/a
 
      07-30-2013
On 30 July 2013 18:08, Vito De Tullio <(E-Mail Removed)> wrote:

> Ed Leafe wrote:
>
> > I had read about a developer who switched to using proportional fonts for
> > coding, and somewhat skeptically, tried it out. After a day or so it
> > stopped looking strange, and after a week it seemed so much easier to
> > read.

>
> By my (limited) experience with proportional fonts, they can be useful only
> with something like elastic tabstops[0]. But, as a general rule, I simply
> found more "squared" to just use a fixed-width font.
>


Not if you give up on the whole "aligning" thing.


> [0] http://nickgravgaard.com/elastictabstops/
>


 
Reply With Quote
 
Grant Edwards
Guest
Posts: n/a
 
      07-30-2013
On 2013-07-30, Joshua Landau <(E-Mail Removed)> wrote:
> On 30 July 2013 18:08, Vito De Tullio <(E-Mail Removed)> wrote:
>
>> Ed Leafe wrote:
>>
>> > I had read about a developer who switched to using proportional fonts for
>> > coding, and somewhat skeptically, tried it out. After a day or so it
>> > stopped looking strange, and after a week it seemed so much easier to
>> > read.

>>
>> By my (limited) experience with proportional fonts, they can be useful only
>> with something like elastic tabstops[0]. But, as a general rule, I simply
>> found more "squared" to just use a fixed-width font.
>>

>
> Not if you give up on the whole "aligning" thing.


You don't think that Python code at a given level should all be
aligned? I find it very helpful when a given block of code is
visually left-aligned.

I also find intializers for tables of data to be much more easily read
and maintained if the columns can be aligned.

--
Grant Edwards grant.b.edwards Yow! MMM-MM!! So THIS is
at BIO-NEBULATION!
gmail.com
 
Reply With Quote
 
Vito De Tullio
Guest
Posts: n/a
 
      07-30-2013
Joshua Landau wrote:

>> By my (limited) experience with proportional fonts, they can be useful
>> only with something like elastic tabstops[0]. But, as a general rule, I
>> simply found more "squared" to just use a fixed-width font.


> Not if you give up on the whole "aligning" thing.



and this is one of the reason why I come back to fixed-width

--
By ZeD

 
Reply With Quote
 
Joshua Landau
Guest
Posts: n/a
 
      07-31-2013
On 30 July 2013 18:52, Grant Edwards <(E-Mail Removed)> wrote:

> On 2013-07-30, Joshua Landau <(E-Mail Removed)> wrote:
> > On 30 July 2013 18:08, Vito De Tullio <(E-Mail Removed)> wrote:
> >
> >> Ed Leafe wrote:
> >>
> >> > I had read about a developer who switched to using proportional fonts

> for
> >> > coding, and somewhat skeptically, tried it out. After a day or so it
> >> > stopped looking strange, and after a week it seemed so much easier to
> >> > read.
> >>
> >> By my (limited) experience with proportional fonts, they can be useful

> only
> >> with something like elastic tabstops[0]. But, as a general rule, I

> simply
> >> found more "squared" to just use a fixed-width font.
> >>

> >
> > Not if you give up on the whole "aligning" thing.

>
> You don't think that Python code at a given level should all be
> aligned? I find it very helpful when a given block of code is
> visually left-aligned.
>


I don't understand what you mean. My coding practices almost never require
anything more than the initial indentation to have things line up -- any
other form of alignment is in my opinion overrated. Maybe it helps you, but
personally I don't like it.

As I've been saying, the whole thing is personal preference and
proportional fonts for some people, such as I, are fine. Except in that
there are no good proportional fonts at 8px .

To explain, I tend to take the "HTML" form of alignment by wrapping:

open stuff stuff stuff close

to

open
stuff
stuff
stuff
close

and thus everything important lines up anyway. Extra non-indentation
indents are a burden for me and look worse (again, personal preference).

I also find intializers for tables of data to be much more easily read
> and maintained if the columns can be aligned.
>


Why do you have tables in your Python code?

 
Reply With Quote
 
Tim Chase
Guest
Posts: n/a
 
      07-31-2013
On 2013-07-31 07:16, Joshua Landau wrote:
> On 30 July 2013 18:52, Grant Edwards wrote:
>> I also find intializers for tables of data to be much more easily
>> read and maintained if the columns can be aligned.

>
> Why do you have tables in your Python code?


I've had occasion to write things like:

for name, value, description in (
("cost", 42, "How much it cost"),
("status", 3141, "Status code from ISO-3.14159"),
...
):
do_something(name, value)
print(description)

I interpret Grant's statement as wanting the "table" to look like

for name, value, description in (
("cost", 42, "How much it cost"),
("status", 3141, "Status code from ISO-3.14159"),
...
):
do_something(name, value)
print(description)

which does give some modest readability benefits, but at a creation
cost I personally am unwilling to pay.

-tkc



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
PEP8 79 char max Devyn Collier Johnson Python 3 07-31-2013 07:30 AM
Re: PEP8 79 char max Joel Goldstick Python 0 07-29-2013 08:08 PM
(const char *cp) and (char *p) are consistent type, (const char **cpp) and (char **pp) are not consistent lovecreatesbeauty C Programming 1 05-09-2006 08:01 AM
/usr/bin/ld: ../../dist/lib/libjsdombase_s.a(BlockGrouper.o)(.text+0x98): unresolvable relocation against symbol `std::basic_ostream<char, std::char_traits<char> >& std::endl<char, std::char_traits<char> >(std::basic_ostre silverburgh.meryl@gmail.com C++ 3 03-09-2006 12:14 AM
the difference between char a[6] and char *p=new char[6] . wwj C++ 7 11-05-2003 12:59 AM



Advertisments