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

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

In defence of 80-char lines

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

Contents

  In defence of 80-char lines Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-04 01:36 +0000
    Re: In defence of 80-char lines Andrew Berg <bahamutzero8825@gmail.com> - 2013-04-03 20:59 -0500
    Re: In defence of 80-char lines Mitya Sirenef <msirenef@lightbird.net> - 2013-04-03 22:40 -0400
    Re: In defence of 80-char lines llanitedave <llanitedave@veawb.coop> - 2013-04-03 21:32 -0700
      Re: In defence of 80-char lines Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-04 06:33 +0000
      Re: In defence of 80-char lines gregor <gregor@ediwo.com> - 2013-04-04 08:40 +0200
      Re: In defence of 80-char lines Peter Otten <__peter__@web.de> - 2013-04-04 08:43 +0200
      Re: In defence of 80-char lines Tim Chase <python.list@tim.thechases.com> - 2013-04-04 06:09 -0500
      Re: In defence of 80-char lines Roy Smith <roy@panix.com> - 2013-04-04 07:52 -0400
        Re: In defence of 80-char lines llanitedave <llanitedave@veawb.coop> - 2013-04-04 08:28 -0700
      Re: In defence of 80-char lines Jason Swails <jason.swails@gmail.com> - 2013-04-04 08:18 -0400
      Re: In defence of 80-char lines Joshua Landau <joshua.landau.ws@gmail.com> - 2013-04-04 18:18 +0100
      Re: In defence of 80-char lines Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-04-04 18:22 -0400
    Re: In defence of 80-char lines rusi <rustompmody@gmail.com> - 2013-04-03 21:56 -0700
    Re: In defence of 80-char lines Rui Maciel <rui.maciel@gmail.com> - 2013-04-04 08:15 +0100
    Re: In defence of 80-char lines Jason Swails <jason.swails@gmail.com> - 2013-04-04 08:13 -0400
      Re: In defence of 80-char lines Roy Smith <roy@panix.com> - 2013-04-04 08:39 -0400
        Re: In defence of 80-char lines Jason Swails <jason.swails@gmail.com> - 2013-04-04 09:23 -0400
        Re: In defence of 80-char lines Neil Cerutti <neilc@norwich.edu> - 2013-04-04 15:56 +0000
        Re: In defence of 80-char lines Kushal Kumaran <kushal.kumaran+python@gmail.com> - 2013-04-04 23:04 +0530
          Re: In defence of 80-char lines Roy Smith <roy@panix.com> - 2013-04-04 19:55 -0400
    Re: In defence of 80-char lines Mitya Sirenef <msirenef@lightbird.net> - 2013-04-04 12:12 -0400
    Re: In defence of 80-char lines jmfauth <wxjmfauth@gmail.com> - 2013-04-04 13:28 -0700
      Re: In defence of 80-char lines Jason Swails <jason.swails@gmail.com> - 2013-04-04 17:00 -0400
      Re: In defence of 80-char lines Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-05 00:14 +0000

Page 2 of 2 — ← Prev page 1 [2]

#42783

In article <mailman.111.1365096868.3114.python-list@python.org>,
 Kushal Kumaran <kushal.kumaran+python@gmail.com> wrote:

> 
> Is using csv.DictReader with delimiter=' ' not sufficient for this?  I
> did not actually read the regular expression in its entirety.

I believe your second sentence answers the question raised in your first 
sentence :-)

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

#42765

On 04/03/2013 09:36 PM, Steven D'Aprano wrote:
> Although PEP 8 is only  compulsory for the Python standard library, many
 > users like to stick to PEP 8 for external projects.
 >
 > http://www.python.org/dev/peps/pep-0008/
 >
 > With perhaps one glaring exception: many people hate, or ignore, PEP 8's
 > recommendation to limit lines to 80 characters. (Strictly speaking, 79
 > characters.)
 >
 >
 > Here is a good defence of 80 char lines:
 >
 > http://wrongsideofmemphis.com/2013/03/25/80-chars-per-line-is-great/
 >
 >
 >


I think one important consideration that wasn't mentioned yet is one of
Python principles: practicality beats purity.

I can see how someone could have a preference for 80 char width, there
are some valid reasons to prefer it. I think other reasons to prefer
(slightly) longer width outweigh them, but that's a judgement call.

However, if you work with other people's code, you will surely run into
all kinds of widths, 100, 120, 140+, etc. For someone with a rigid 80
limit, it's a real pain. I feel that somewhere around 100 width, must be
the reasonable middle ground: for me at soft 105 limit, editing 80 limit
code feels almost like my own, in fact the range of 80-110 is going to
fit neatly into my setup without any hassle.

120 is minimal hassle: I adjust Gvim to take a bit more space, resize
browser to take a bit less space and I'm set.

140 is a bit uncomfortable, but I generally notice that even when people
code to 140 limit, nearly all of their lines are actually going to be at
about 120 limit at most, with only a few offenders, so it's trivial to
adjust to 120 limit.

If people go over 140, that conclusively proves they're smoking crack
and the code needs to be refactored anyway.


I also find the argument about 80 width used in books a little odd. I
read webpages with 100-140 widths all the time with not the slightest
problem. As far as I know, no browser in existence lets you uniformly
adjust all pages to wrap at 80 limit except for lynx/links; if it was
hard to read at wider sizes, surely there would be at least one
graphical browser that would give that option (and get all the user
share from other browsers?)

Code is rather different from regular text. I would not want my books
formatted like this:

The story had held us, round the fire, sufficiently breathless, but
                                                     except the obvious
                                                     remark that it was
                                                     gruesome, as,

on Christmas Eve in an old house, a strange tale should essentially be,
I remember no comment uttered till somebody
happened to say that
it was the only case he had met in which such a visitation
                                                         had fallen on a
                                                         child.


Nor am I (warning: understatement) particularly enthusiastic about
editing code that looks like (formatted to 72 width):


try: request = self.request_class(environ) except UnicodeDecodeError:
logger.warning('Bad Request (UnicodeDecodeError)',
exc_info=sys.exc_info(), extra={ 'status_code': 400, }) response =
http.HttpResponseBadRequest() else: response =
self.get_response(request)

response._handler_class = self.__class__

try: status_text = STATUS_CODE_TEXT[response.status_code] except
KeyError: status_text = 'UNKNOWN STATUS CODE' status = '%s %s' %
(response.status_code, status_text) response_headers = [(str(k), str(v))
for k, v in response.items()] for c in response.cookies.values():
response_headers.append((str('Set-Cookie'), str(c.output(header=''))))
start_response(force_str(status), response_headers) return response


  -m



-- 
Lark's Tongue Guide to Python: http://lightbird.net/larks/

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

#42776

On 4 avr, 03:36, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:
> Although PEP 8 is only compulsory for the Python standard library, many
> users like to stick to PEP 8 for external projects.
>
> http://www.python.org/dev/peps/pep-0008/
>
> With perhaps one glaring exception: many people hate, or ignore, PEP 8's
> recommendation to limit lines to 80 characters. (Strictly speaking, 79
> characters.)
>
> Here is a good defence of 80 char lines:
>
> http://wrongsideofmemphis.com/2013/03/25/80-chars-per-line-is-great/
>
> --
> Steven

-----

With "unicode fonts", where even the monospaced fonts
present char widths with a variable width depending on
the unicode block (obvious reasons), speaking of a "text
width" in chars has not even a sense.

jmf

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

#42778

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

On Thu, Apr 4, 2013 at 4:28 PM, jmfauth <wxjmfauth@gmail.com> wrote:

> On 4 avr, 03:36, Steven D'Aprano <steve
> +comp.lang.pyt...@pearwood.info> wrote:
> > Although PEP 8 is only compulsory for the Python standard library, many
> > users like to stick to PEP 8 for external projects.
> >
> > http://www.python.org/dev/peps/pep-0008/
> >
> > With perhaps one glaring exception: many people hate, or ignore, PEP 8's
> > recommendation to limit lines to 80 characters. (Strictly speaking, 79
> > characters.)
> >
> > Here is a good defence of 80 char lines:
> >
> > http://wrongsideofmemphis.com/2013/03/25/80-chars-per-line-is-great/
> >
> > --
> > Steven
>
> -----
>
> With "unicode fonts",


Didn't see this coming.


> where even the monospaced fonts
> present char widths with a variable width depending on
> the unicode block (obvious reasons), speaking of a "text
> width" in chars has not even a sense.
>

Let's log this as an exception to the rule of 80.  There are plenty of
threads not-about-Unicode-but-are-now-about-Unicode that we don't have to
create another one.

Jason

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

#42785

On Thu, 04 Apr 2013 13:28:04 -0700, jmfauth wrote:

> With "unicode fonts", where even the monospaced fonts present char
> widths with a variable width depending on the unicode block (obvious
> reasons), speaking of a "text width" in chars has not even a sense.

A properly-designed Unicode monospaced font should still be monospaced. 
Or at worst, bispaced, if it also supports East Asian halfwidth and 
fullwidth forms. In that case, the text width in chars should be 
interpreted as halfwidth chars. Or if you prefer, the rule can be 
interpreted as:

Line width should be no greater than 79 halfwidth characters, or 39 
fullwidth characters, or some combination thereof.

http://en.wikipedia.org/wiki/Halfwidth_and_fullwidth_forms


-- 
Steven

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web