Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #107077 > unrolled thread
| Started by | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| First post | 2016-04-16 14:38 +1000 |
| Last post | 2016-04-18 05:45 +1000 |
| Articles | 20 on this page of 142 — 36 participants |
Back to article view | Back to comp.lang.python
Guido sees the light: PEP 8 updated Steven D'Aprano <steve@pearwood.info> - 2016-04-16 14:38 +1000
Re: Guido sees the light: PEP 8 updated Bob Martin <bob.martin@excite.com> - 2016-04-16 08:05 +0100
Re: Guido sees the light: PEP 8 updated Marko Rauhamaa <marko@pacujo.net> - 2016-04-16 11:06 +0300
Re: Guido sees the light: PEP 8 updated Chris Angelico <rosuav@gmail.com> - 2016-04-16 18:32 +1000
Re: Guido sees the light: PEP 8 updated Marko Rauhamaa <marko@pacujo.net> - 2016-04-16 11:51 +0300
Re: Guido sees the light: PEP 8 updated Chris Angelico <rosuav@gmail.com> - 2016-04-16 19:30 +1000
Re: Guido sees the light: PEP 8 updated Michael Selik <michael.selik@gmail.com> - 2016-04-16 09:34 +0000
Re: Guido sees the light: PEP 8 updated Steven D'Aprano <steve@pearwood.info> - 2016-04-16 22:03 +1000
Re: Guido sees the light: PEP 8 updated Stephen Hansen <me+python@ixokai.io> - 2016-04-16 05:32 -0700
Re: Guido sees the light: PEP 8 updated Larry Martell <larry.martell@gmail.com> - 2016-04-16 10:53 -0400
Re: Guido sees the light: PEP 8 updated Marko Rauhamaa <marko@pacujo.net> - 2016-04-16 19:51 +0300
Re: Guido sees the light: PEP 8 updated Larry Martell <larry.martell@gmail.com> - 2016-04-16 12:58 -0400
Re: Guido sees the light: PEP 8 updated BartC <bc@freeuk.com> - 2016-04-16 19:18 +0100
Re: Guido sees the light: PEP 8 updated Larry Martell <larry.martell@gmail.com> - 2016-04-16 14:53 -0400
Re: Guido sees the light: PEP 8 updated alex wright <wrightalexw@gmail.com> - 2016-04-16 15:21 -0400
Re: Guido sees the light: PEP 8 updated Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-04-16 19:08 -0400
Re: Guido sees the light: PEP 8 updated Terry Reedy <tjreedy@udel.edu> - 2016-04-16 13:25 -0400
Re: Guido sees the light: PEP 8 updated Marko Rauhamaa <marko@pacujo.net> - 2016-04-16 21:33 +0300
Re: Guido sees the light: PEP 8 updated Ethan Furman <ethan@stoneleaf.us> - 2016-04-16 12:07 -0700
Re: Guido sees the light: PEP 8 updated Ben Finney <ben+python@benfinney.id.au> - 2016-04-17 06:08 +1000
Re: Guido sees the light: PEP 8 updated Tim Chase <python.list@tim.thechases.com> - 2016-04-16 16:50 -0500
Re: Guido sees the light: PEP 8 updated Tim Delaney <timothy.c.delaney@gmail.com> - 2016-04-17 08:15 +1000
Re: Guido sees the light: PEP 8 updated Marko Rauhamaa <marko@pacujo.net> - 2016-04-17 01:30 +0300
Re: Guido sees the light: PEP 8 updated Ian Kelly <ian.g.kelly@gmail.com> - 2016-04-17 07:38 -0600
Re: Guido sees the light: PEP 8 updated Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-04-16 19:02 -0400
Re: Guido sees the light: PEP 8 updated Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-04-17 00:25 +0100
Re: Guido sees the light: PEP 8 updated Chris Angelico <rosuav@gmail.com> - 2016-04-17 09:33 +1000
Re: Guido sees the light: PEP 8 updated Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-04-17 01:29 +0100
Re: Guido sees the light: PEP 8 updated alex wright <wrightalexw@gmail.com> - 2016-04-16 19:43 -0400
Re: Guido sees the light: PEP 8 updated Chris Angelico <rosuav@gmail.com> - 2016-04-17 09:11 +1000
Re: Guido sees the light: PEP 8 updated Grant Edwards <grant.b.edwards@gmail.com> - 2016-04-16 23:19 +0000
Re: Guido sees the light: PEP 8 updated Tim Chase <python.list@tim.thechases.com> - 2016-04-16 19:12 -0500
Re: Guido sees the light: PEP 8 updated MRAB <python@mrabarnett.plus.com> - 2016-04-17 01:24 +0100
Re: Guido sees the light: PEP 8 updated Tim Chase <python.list@tim.thechases.com> - 2016-04-16 20:30 -0500
Re: Guido sees the light: PEP 8 updated Coos Haak <chforth@hccnet.nl> - 2016-04-17 16:35 +0200
Re: Guido sees the light: PEP 8 updated Tim Chase <python.list@tim.thechases.com> - 2016-04-17 13:11 -0500
Re: Guido sees the light: PEP 8 updated Random832 <random832@fastmail.com> - 2016-04-16 21:59 -0400
Re: Guido sees the light: PEP 8 updated Rustom Mody <rustompmody@gmail.com> - 2016-04-16 20:44 -0700
Re: Guido sees the light: PEP 8 updated Chris Angelico <rosuav@gmail.com> - 2016-04-17 13:49 +1000
Re: Guido sees the light: PEP 8 updated Rustom Mody <rustompmody@gmail.com> - 2016-04-17 18:39 -0700
Re: Guido sees the light: PEP 8 updated Steven D'Aprano <steve@pearwood.info> - 2016-04-18 13:19 +1000
Re: Guido sees the light: PEP 8 updated Rustom Mody <rustompmody@gmail.com> - 2016-04-17 20:48 -0700
Re: Guido sees the light: PEP 8 updated David Palao <dpalao.python@gmail.com> - 2016-04-18 13:35 +0200
Re: Guido sees the light: PEP 8 updated BartC <bc@freeuk.com> - 2016-04-17 11:04 +0100
Re: Guido sees the light: PEP 8 updated Rustom Mody <rustompmody@gmail.com> - 2016-04-17 21:06 -0700
Re: Guido sees the light: PEP 8 updated Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-04-18 21:03 +1200
Re: Guido sees the light: PEP 8 updated Rustom Mody <rustompmody@gmail.com> - 2016-04-18 04:07 -0700
Re: Guido sees the light: PEP 8 updated Marko Rauhamaa <marko@pacujo.net> - 2016-04-17 14:01 +0300
Re: Guido sees the light: PEP 8 updated Chris Angelico <rosuav@gmail.com> - 2016-04-17 21:14 +1000
Re: Guido sees the light: PEP 8 updated BartC <bc@freeuk.com> - 2016-04-17 13:04 +0100
Re: Guido sees the light: PEP 8 updated Marko Rauhamaa <marko@pacujo.net> - 2016-04-17 15:10 +0300
Re: Guido sees the light: PEP 8 updated Ben Finney <ben+python@benfinney.id.au> - 2016-04-18 08:13 +1000
Re: Guido sees the light: PEP 8 updated Steven D'Aprano <steve@pearwood.info> - 2016-04-18 11:57 +1000
Re: Guido sees the light: PEP 8 updated Marko Rauhamaa <marko@pacujo.net> - 2016-04-18 11:02 +0300
Re: Guido sees the light: PEP 8 updated Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-04-18 20:43 +1200
Re: Guido sees the light: PEP 8 updated Marko Rauhamaa <marko@pacujo.net> - 2016-04-18 12:17 +0300
Re: Guido sees the light: PEP 8 updated eryk sun <eryksun@gmail.com> - 2016-04-17 00:01 -0500
Re: Guido sees the light: PEP 8 updated Random832 <random832@fastmail.com> - 2016-04-17 01:10 -0400
Re: Guido sees the light: PEP 8 updated eryk sun <eryksun@gmail.com> - 2016-04-17 03:14 -0500
Re: Guido sees the light: PEP 8 updated Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-04-17 12:13 -0400
Re: Guido sees the light: PEP 8 updated eryk sun <eryksun@gmail.com> - 2016-04-17 15:24 -0500
Re: Guido sees the light: PEP 8 updated Michael Torrie <torriem@gmail.com> - 2016-04-17 14:41 -0600
Re: Guido sees the light: PEP 8 updated Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-04-18 11:56 +1200
Re: Guido sees the light: PEP 8 updated Random832 <random832@fastmail.com> - 2016-04-17 20:29 -0400
Re: Guido sees the light: PEP 8 updated Sivan Greenberg <sivan@vitakka.co> - 2016-04-18 16:35 +0300
Re: Guido sees the light: PEP 8 updated Pete Forman <petef4+usenet@gmail.com> - 2016-04-18 22:14 +0100
Re: Guido sees the light: PEP 8 updated Ian Kelly <ian.g.kelly@gmail.com> - 2016-04-18 15:29 -0600
Re: Guido sees the light: PEP 8 updated Pete Forman <petef4+usenet@gmail.com> - 2016-04-18 23:20 +0100
Re: Guido sees the light: PEP 8 updated Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-04-19 17:39 +1200
Re: Guido sees the light: PEP 8 updated Ben Finney <ben+python@benfinney.id.au> - 2016-04-19 08:58 +1000
Re: Guido sees the light: PEP 8 updated sohcahtoa82@gmail.com - 2016-04-18 18:19 -0700
Re: Guido sees the light: PEP 8 updated Rustom Mody <rustompmody@gmail.com> - 2016-04-18 20:04 -0700
Re: Guido sees the light: PEP 8 updated Random832 <random832@fastmail.com> - 2016-04-18 23:29 -0400
Re: Guido sees the light: PEP 8 updated Rustom Mody <rustompmody@gmail.com> - 2016-04-18 20:54 -0700
Re: Guido sees the light: PEP 8 updated Random832 <random832@fastmail.com> - 2016-04-19 00:11 -0400
Re: Guido sees the light: PEP 8 updated Rustom Mody <rustompmody@gmail.com> - 2016-04-19 05:55 -0700
Re: Guido sees the light: PEP 8 updated Random832 <random832@fastmail.com> - 2016-04-19 10:05 -0400
Re: Guido sees the light: PEP 8 updated Chris Angelico <rosuav@gmail.com> - 2016-04-20 00:13 +1000
Re: Guido sees the light: PEP 8 updated Pete Forman <petef4+usenet@gmail.com> - 2016-04-19 08:34 +0100
Re: Guido sees the light: PEP 8 updated Ben Finney <ben+python@benfinney.id.au> - 2016-04-19 18:04 +1000
Re: Guido sees the light: PEP 8 updated Marko Rauhamaa <marko@pacujo.net> - 2016-04-19 11:09 +0300
Re: Guido sees the light: PEP 8 updated Chris Angelico <rosuav@gmail.com> - 2016-04-19 18:17 +1000
Re: Guido sees the light: PEP 8 updated Rustom Mody <rustompmody@gmail.com> - 2016-04-19 04:37 -0700
Re: Guido sees the light: PEP 8 updated Tim Chase <python.list@tim.thechases.com> - 2016-04-19 08:17 -0500
Re: Guido sees the light: PEP 8 updated Rustom Mody <rustompmody@gmail.com> - 2016-04-19 07:10 -0700
Re: Guido sees the light: PEP 8 updated Grant Edwards <grant.b.edwards@gmail.com> - 2016-04-19 14:15 +0000
Re: Guido sees the light: PEP 8 updated Rustom Mody <rustompmody@gmail.com> - 2016-04-19 07:54 -0700
Re: Guido sees the light: PEP 8 updated Steven D'Aprano <steve@pearwood.info> - 2016-04-20 01:50 +1000
Re: Guido sees the light: PEP 8 updated Steven D'Aprano <steve@pearwood.info> - 2016-04-20 01:58 +1000
Re: Guido sees the light: PEP 8 updated Larry Martell <larry.martell@gmail.com> - 2016-04-19 13:06 -0400
Re: Guido sees the light: PEP 8 updated alister <alister.ware@ntlworld.com> - 2016-04-19 17:13 +0000
Re: Guido sees the light: PEP 8 updated Chris Angelico <rosuav@gmail.com> - 2016-04-20 00:24 +1000
Re: Guido sees the light: PEP 8 updated Steven D'Aprano <steve@pearwood.info> - 2016-04-20 02:14 +1000
Re: Guido sees the light: PEP 8 updated Rustom Mody <rustompmody@gmail.com> - 2016-04-19 09:46 -0700
Re: Guido sees the light: PEP 8 updated Tim Chase <python.list@tim.thechases.com> - 2016-04-19 12:43 -0500
Re: Guido sees the light: PEP 8 updated Rustom Mody <rustompmody@gmail.com> - 2016-04-19 11:05 -0700
Re: Guido sees the light: PEP 8 updated Random832 <random832@fastmail.com> - 2016-04-19 14:54 -0400
Re: Guido sees the light: PEP 8 updated Steven D'Aprano <steve@pearwood.info> - 2016-04-20 10:34 +1000
Re: Guido sees the light: PEP 8 updated Random832 <random832@fastmail.com> - 2016-04-19 22:02 -0400
Re: Guido sees the light: PEP 8 updated Steven D'Aprano <steve@pearwood.info> - 2016-04-20 11:38 +1000
Re: Guido sees the light: PEP 8 updated Chris Angelico <rosuav@gmail.com> - 2016-04-20 12:21 +1000
Re: Guido sees the light: PEP 8 updated Terry Reedy <tjreedy@udel.edu> - 2016-04-19 23:23 -0400
Re: Guido sees the light: PEP 8 updated Chris Angelico <rosuav@gmail.com> - 2016-04-20 13:41 +1000
Re: Guido sees the light: PEP 8 updated Terry Reedy <tjreedy@udel.edu> - 2016-04-20 02:08 -0400
Re: Guido sees the light: PEP 8 updated wxjmfauth@gmail.com - 2016-04-20 00:48 -0700
Re: Guido sees the light: PEP 8 updated Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2016-04-20 10:24 +0100
Re: Guido sees the light: PEP 8 updated Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2016-04-20 10:26 +0100
Re: Guido sees the light: PEP 8 updated Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-04-20 07:51 -0400
Re: Guido sees the light: PEP 8 updated Rustom Mody <rustompmody@gmail.com> - 2016-04-19 21:04 -0700
Re: Guido sees the light: PEP 8 updated Ben Finney <ben+python@benfinney.id.au> - 2016-04-20 06:50 +1000
Re: Guido sees the light: PEP 8 updated Chris Angelico <rosuav@gmail.com> - 2016-04-20 06:59 +1000
Re: Guido sees the light: PEP 8 updated Marko Rauhamaa <marko@pacujo.net> - 2016-04-20 00:35 +0300
Re: Guido sees the light: PEP 8 updated Steven D'Aprano <steve@pearwood.info> - 2016-04-20 11:03 +1000
Re: Guido sees the light: PEP 8 updated Rustom Mody <rustompmody@gmail.com> - 2016-04-19 21:13 -0700
Re: Guido sees the light: PEP 8 updated Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-04-20 18:39 +1200
Re: Guido sees the light: PEP 8 updated sohcahtoa82@gmail.com - 2016-04-19 14:43 -0700
Re: Guido sees the light: PEP 8 updated Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-04-19 19:20 -0400
Re: Guido sees the light: PEP 8 updated Grant Edwards <grant.b.edwards@gmail.com> - 2016-04-19 23:22 +0000
Re: Guido sees the light: PEP 8 updated Chris Angelico <rosuav@gmail.com> - 2016-04-20 09:33 +1000
Re: Guido sees the light: PEP 8 updated Tim Chase <python.list@tim.thechases.com> - 2016-04-19 19:02 -0500
Re: Guido sees the light: PEP 8 updated Steven D'Aprano <steve@pearwood.info> - 2016-04-20 10:32 +1000
Re: Guido sees the light: PEP 8 updated Random832 <random832@fastmail.com> - 2016-04-19 21:57 -0400
Re: Guido sees the light: PEP 8 updated wxjmfauth@gmail.com - 2016-04-19 01:49 -0700
Re: Guido sees the light: PEP 8 updated Paul Rudin <paul.nospam@rudin.co.uk> - 2016-04-19 11:49 +0100
Re: Guido sees the light: PEP 8 updated Marko Rauhamaa <marko@pacujo.net> - 2016-04-19 14:47 +0300
Re: Guido sees the light: PEP 8 updated Rustom Mody <rustompmody@gmail.com> - 2016-04-19 05:06 -0700
Re: Guido sees the light: PEP 8 updated Marko Rauhamaa <marko@pacujo.net> - 2016-04-19 15:14 +0300
Re: Guido sees the light: PEP 8 updated Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-04-19 15:07 +0200
Re: Guido sees the light: PEP 8 updated Tim Chase <python.list@tim.thechases.com> - 2016-04-19 08:31 -0500
Re: Guido sees the light: PEP 8 updated Chris Angelico <rosuav@gmail.com> - 2016-04-19 23:41 +1000
Re: Guido sees the light: PEP 8 updated Tim Chase <python.list@tim.thechases.com> - 2016-04-19 08:50 -0500
Re: Guido sees the light: PEP 8 updated Alice Bevan–McGregor <alice@gothcandy.com> - 2016-04-19 10:45 -0400
Falsehoods People Believe about PEP 8 (was: Guido sees the light: PEP 8 updated) Ben Finney <ben+python@benfinney.id.au> - 2016-04-17 06:21 +1000
Re: Falsehoods People Believe about PEP 8 (was: Guido sees the light: PEP 8 updated) Chris Angelico <rosuav@gmail.com> - 2016-04-17 06:31 +1000
Re: Falsehoods People Believe about PEP 8 (was: Guido sees the light: PEP 8 updated) Random832 <random832@fastmail.com> - 2016-04-16 16:44 -0400
Re: Falsehoods People Believe about PEP 8 (was: Guido sees the light: PEP 8 updated) Dan Sommers <dan@tombstonezero.net> - 2016-04-16 21:22 +0000
Re: Falsehoods People Believe about PEP 8 (was: Guido sees the light: PEP 8 updated) Chris Angelico <rosuav@gmail.com> - 2016-04-17 07:34 +1000
Re: Falsehoods People Believe about PEP 8 (was: Guido sees the light: PEP 8 updated) Dan Sommers <dan@tombstonezero.net> - 2016-04-16 23:35 +0000
Re: Falsehoods People Believe about PEP 8 (was: Guido sees the light: PEP 8 updated) Steven D'Aprano <steve@pearwood.info> - 2016-04-17 11:48 +1000
Re: Falsehoods People Believe about PEP 8 (was: Guido sees the light: PEP 8 updated) Dan Sommers <dan@tombstonezero.net> - 2016-04-17 03:52 +0000
Re: Falsehoods People Believe about PEP 8 (was: Guido sees the light: PEP 8 updated) Steven D'Aprano <steve@pearwood.info> - 2016-04-17 11:38 +1000
Re: Falsehoods People Believe about PEP 8 (was: Guido sees the light: PEP 8 updated) Chris Angelico <rosuav@gmail.com> - 2016-04-18 05:45 +1000
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-04-18 13:19 +1000 |
| Message-ID | <5714522d$0$1622$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #107218 |
On Mon, 18 Apr 2016 11:39 am, Rustom Mody wrote:
> yes we can agree on this -- arbitrary line lengths are almost certainly
> unreadable.
> The problem then becomes so what is optimal?
I really don't think it is a problem. We have about 400 years
of experience with printed text, and that experience tells us
that the optimal width for reading prose in Western languages
is about 60 characters, give or take. This width is optimal
for eye movement, and minimizes the number of errors and
reduces eye-strain.
There's only so far that our eyes can follow a line to the
right without increasing stress or reading errors, and
likewise when returning back to the left margin. The longer
the line, the higher the chance of losing track, and the
physical effort it takes to read. (You have to move the eyes
further, and for extremely long lines, you may have to move
your entire head.)
Long lines are simply harder to read because you have to
move your eyes more, and the longer the lines, the greater
the tendency to wander across the lines. Especially if the
lines are close together and the height of the lines is
small. (It boggles my mind how many programmers I've met who
routinely view their code in tiny physical heights, even
when reading it in fine detail.)
The optimal width for eye-tracking (that is, the maximum
width for which the rate of such errors can be disregarded)
is somewhere about sixty characters per line.
The same eye-tracking considerations apply to code, but:
when it comes to code, we don't always have to track all the
way back to the left-hand margin. If we start (say) up to
twenty columns in, then we can afford to write up to twenty
columns further to the right too.
(Also, code tends to have VERY ragged right-hand margins.
Not all lines end up even close to sixty characters wide.)
There are other considerations though. Unlike prose, with
code, shorter lines *may* sometimes force an increase in
complexity. For instance, temporary variables need to be
created, or new functions created, just to avoid otherwise
excessively long lines. So one might be willing to accept a
little more eye-movement for a little less code complexity.
So allowing a total width of 80 (give or take) is already a
compromise from the optimal sixty characters. This compromise
allows for indented code, and allows up to 20 characters
extra to avoid creating more complexity elsewhere.
But there's another factor: long lines of code are themselves
a code-smell. Perhaps:
- you have indented too deeply, suggesting that your function
is doing too much or has too much internal complexity:
def func():
if a:
for b in seq:
while c:
with d:
try:
try:
for e in it:
block # only 48 columns available here
(But note also that even with this extreme example, eight
indentation levels deep, you can still fit almost
characters per line without breaking the 80-char limit.
You can do a lot in 50 characters.)
- you have too many expressions on one line, suggesting that
the over-all complexity of the line is excessive;
- your variable or function names are needlessly verbose or
are doing too much or are too specific
("calculate_number_of_pages_and_number_of_semicolons_in_chapter_one");
- or you are violating the rule of Demeter:
get(customer.trousers.pocket.wallet).open().money.pay(1)
In other words, long lines of code are themselves an
indication of poorly-designed code. Even though there are
exceptions, we should resist strongly the urge to extend
beyond the 60-80 (or perhaps 90 in extreme cases) limit.
Whenever I hear people saying that they regularly need to
use 100 or even 120 columns for their code, what I hear is
"my code is badly written".
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2016-04-17 20:48 -0700 |
| Message-ID | <b5264346-0aab-4dd0-8be2-259fc0898547@googlegroups.com> |
| In reply to | #107226 |
On Monday, April 18, 2016 at 8:49:33 AM UTC+5:30, Steven D'Aprano wrote: > On Mon, 18 Apr 2016 11:39 am, Rustom Mody wrote: > > > yes we can agree on this -- arbitrary line lengths are almost certainly > > unreadable. > > The problem then becomes so what is optimal? > > I really don't think it is a problem. We have about 400 years > of experience with printed text, and that experience tells us > that the optimal width for reading prose in Western languages > is about 60 characters, give or take. This width is optimal > for eye movement, and minimizes the number of errors and > reduces eye-strain. No disagreement so far > > There's only so far that our eyes can follow a line to the > right without increasing stress or reading errors, and > likewise when returning back to the left margin. The longer > the line, the higher the chance of losing track, and the > physical effort it takes to read. (You have to move the eyes > further, and for extremely long lines, you may have to move > your entire head.) > > Long lines are simply harder to read because you have to > move your eyes more, and the longer the lines, the greater > the tendency to wander across the lines. Especially if the > lines are close together and the height of the lines is > small. (It boggles my mind how many programmers I've met who > routinely view their code in tiny physical heights, even > when reading it in fine detail.) > > The optimal width for eye-tracking (that is, the maximum > width for which the rate of such errors can be disregarded) > is somewhere about sixty characters per line. Maybe even this is ok > > The same eye-tracking considerations apply to code This is nonsense. The last attempt of making code text-ish was Cobol -- by most accounts an unhappy experience. What is more code needs to be read very intensively for comprehension "x... what is x where is it defined? (scan backwards) ah there? Uh no further back... No global..." My own estimate of increased back-n-forth scanning of code vs plain text is probably an order of magnitude ie close to 10 times Even if I grant that you are twice as good a programmer as I am it will become 5 times. You would have to be 10 times better than me to equalize to (my) plaintext rate But if you are that kind of genius you probably speed-read plain text as well. tl;dr 1. Different languages -- natural and computer -- have different optimal line lengths. 2. There is very scant data on that. 3. PEP8 style strictures only delay discovery and collection of such data
[toc] | [prev] | [next] | [standalone]
| From | David Palao <dpalao.python@gmail.com> |
|---|---|
| Date | 2016-04-18 13:35 +0200 |
| Message-ID | <mailman.147.1460979350.6324.python-list@python.org> |
| In reply to | #107226 |
2016-04-18 5:19 GMT+02:00 Steven D'Aprano <steve@pearwood.info>:
> On Mon, 18 Apr 2016 11:39 am, Rustom Mody wrote:
>
>> yes we can agree on this -- arbitrary line lengths are almost certainly
>> unreadable.
>> The problem then becomes so what is optimal?
>
> I really don't think it is a problem. We have about 400 years
> of experience with printed text, and that experience tells us
> that the optimal width for reading prose in Western languages
> is about 60 characters, give or take. This width is optimal
> for eye movement, and minimizes the number of errors and
> reduces eye-strain.
>
> There's only so far that our eyes can follow a line to the
> right without increasing stress or reading errors, and
> likewise when returning back to the left margin. The longer
> the line, the higher the chance of losing track, and the
> physical effort it takes to read. (You have to move the eyes
> further, and for extremely long lines, you may have to move
> your entire head.)
>
> Long lines are simply harder to read because you have to
> move your eyes more, and the longer the lines, the greater
> the tendency to wander across the lines. Especially if the
> lines are close together and the height of the lines is
> small. (It boggles my mind how many programmers I've met who
> routinely view their code in tiny physical heights, even
> when reading it in fine detail.)
>
> The optimal width for eye-tracking (that is, the maximum
> width for which the rate of such errors can be disregarded)
> is somewhere about sixty characters per line.
>
> The same eye-tracking considerations apply to code, but:
>
> when it comes to code, we don't always have to track all the
> way back to the left-hand margin. If we start (say) up to
> twenty columns in, then we can afford to write up to twenty
> columns further to the right too.
>
>
> (Also, code tends to have VERY ragged right-hand margins.
> Not all lines end up even close to sixty characters wide.)
>
> There are other considerations though. Unlike prose, with
> code, shorter lines *may* sometimes force an increase in
> complexity. For instance, temporary variables need to be
> created, or new functions created, just to avoid otherwise
> excessively long lines. So one might be willing to accept a
> little more eye-movement for a little less code complexity.
>
> So allowing a total width of 80 (give or take) is already a
> compromise from the optimal sixty characters. This compromise
> allows for indented code, and allows up to 20 characters
> extra to avoid creating more complexity elsewhere.
>
>
> But there's another factor: long lines of code are themselves
> a code-smell. Perhaps:
>
> - you have indented too deeply, suggesting that your function
> is doing too much or has too much internal complexity:
>
> def func():
> if a:
> for b in seq:
> while c:
> with d:
> try:
> try:
> for e in it:
> block # only 48 columns available here
>
> (But note also that even with this extreme example, eight
> indentation levels deep, you can still fit almost
> characters per line without breaking the 80-char limit.
> You can do a lot in 50 characters.)
>
>
> - you have too many expressions on one line, suggesting that
> the over-all complexity of the line is excessive;
>
> - your variable or function names are needlessly verbose or
> are doing too much or are too specific
> ("calculate_number_of_pages_and_number_of_semicolons_in_chapter_one");
>
> - or you are violating the rule of Demeter:
> get(customer.trousers.pocket.wallet).open().money.pay(1)
>
>
> In other words, long lines of code are themselves an
> indication of poorly-designed code. Even though there are
> exceptions, we should resist strongly the urge to extend
> beyond the 60-80 (or perhaps 90 in extreme cases) limit.
> Whenever I hear people saying that they regularly need to
> use 100 or even 120 columns for their code, what I hear is
> "my code is badly written".
>
>
>
> --
> Steven
>
> --
> https://mail.python.org/mailman/listinfo/python-list
Excellent! Thank you for this contribution.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-04-17 11:04 +0100 |
| Message-ID | <nevmtj$kj2$1@dont-email.me> |
| In reply to | #107154 |
On 17/04/2016 04:44, Rustom Mody wrote: > On Saturday, April 16, 2016 at 10:22:10 PM UTC+5:30, Marko Rauhamaa wrote: >> It comes with the maxim that one function must be visible at once on the >> screen. > > Thats a strange self-contradiction. I wrote this: > http://blog.languager.org/2012/10/layout-imperative-in-functional.html > to make the case against PEP8 style line length strictures. > Which has the SAME code formatted in two styles: > > -- < 80 cols, 48 lines > -- 115 cols 37 lines > > Clearly the 115 cols is MORE fittable in a page than the 80 cols > [Though my argument for that is based on other structural/semantic principles] Um, that's a different language, or does PEP8 apply to Haskell too? Haskell has a style that likes to be written horizontally (rather than have statements one after another - /on separate lines/ - as in imperative code). I also have trouble regarding that code as a single function, as it implements (AFAICS) an entire lexer. It resembles data more than anything else, and data presumably is allowed to be scrolled. Otherwise things would be very restrictive! -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2016-04-17 21:06 -0700 |
| Message-ID | <91134e90-1cce-471b-9f5a-616276886e84@googlegroups.com> |
| In reply to | #107167 |
On Sunday, April 17, 2016 at 3:34:56 PM UTC+5:30, BartC wrote: > On 17/04/2016 04:44, Rustom Mody wrote: > > On Saturday, April 16, 2016 at 10:22:10 PM UTC+5:30, Marko Rauhamaa wrote: > > >> It comes with the maxim that one function must be visible at once on the > >> screen. > > > > Thats a strange self-contradiction. I wrote this: > > http://blog.languager.org/2012/10/layout-imperative-in-functional.html > > to make the case against PEP8 style line length strictures. > > Which has the SAME code formatted in two styles: > > > > -- < 80 cols, 48 lines > > -- 115 cols 37 lines > > > > Clearly the 115 cols is MORE fittable in a page than the 80 cols > > [Though my argument for that is based on other structural/semantic principles] > > Um, that's a different language, or does PEP8 apply to Haskell too? > > Haskell has a style that likes to be written horizontally (rather than > have statements one after another - /on separate lines/ - as in > imperative code). > > I also have trouble regarding that code as a single function, as it > implements (AFAICS) an entire lexer. It resembles data more than > anything else, and data presumably is allowed to be scrolled. Thats a nice point ... and often neglected by even the aficionados of functional programming. See Data Orientation http://blog.languager.org/2012/10/functional-programming-lost-booty.html [yeah funny that I am tell you this given your recent famous thread on lexing!] Come to think of it take an SQL DBMS browser. Should we say: Horizontal scrolls are BAD; just reformat the table after reaching 80 columns? In fact much of the point of http://blog.languager.org/2012/10/layout-imperative-in-functional.html is just this: that as code becomes more and more data-ish, a more-lines-less-columns regime becomes correspondingly irksome. > Otherwise things would be very restrictive! Dont understand that comment
[toc] | [prev] | [next] | [standalone]
| From | Gregory Ewing <greg.ewing@canterbury.ac.nz> |
|---|---|
| Date | 2016-04-18 21:03 +1200 |
| Message-ID | <dnjm7sFuaseU1@mid.individual.net> |
| In reply to | #107232 |
Rustom Mody wrote: > Come to think of it take an SQL DBMS browser. > Should we say: Horizontal scrolls are BAD; just reformat the table after reaching 80 columns? I would say, yes, horizontal scrolling *is* bad in a table -- probably even worse than it is for text or code. The reason is that tables are usually laid out so that data items in a row are related to each other. You can't make sense of a piece of data in the table without seeing the other items in the same row. That's hard to do if you can't see the whole row at once. > In fact much of the point of > http://blog.languager.org/2012/10/layout-imperative-in-functional.html > is just this: that as code becomes more and more data-ish, > a more-lines-less-columns regime becomes correspondingly irksome. I draw the opposite conclusion. The more your code is laid out like a table, the more important it is to be able to see the whole width of it at once. Your Haskell lexer example looks all very nice in a good wide browser window. But reduce it so you can only see half of it at a time and then tell me how readable it is. -- Greg
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2016-04-18 04:07 -0700 |
| Message-ID | <3ca5df02-dfd5-4e1f-8e2f-e7a6d1231987@googlegroups.com> |
| In reply to | #107257 |
On Monday, April 18, 2016 at 2:34:10 PM UTC+5:30, Gregory Ewing wrote: > Rustom Mody wrote: > > Come to think of it take an SQL DBMS browser. > > Should we say: Horizontal scrolls are BAD; just reformat the table after reaching 80 columns? > > I would say, yes, horizontal scrolling *is* bad in a table -- > probably even worse than it is for text or code. > > The reason is that tables are usually laid out so that > data items in a row are related to each other. You can't > make sense of a piece of data in the table without seeing > the other items in the same row. That's hard to do if > you can't see the whole row at once. "horizontal scrolling: BAD" + "Need to see whole row at once" How to reconcile these two? (Think of a 50 column table/spreadsheet) The only answer I know in DBMS lingo is "normalize" (refactor in programming lingo) which one way or other amounts to "Store some of those columns in your head" Obviously I am not against normalization when it actually cleans up I am against normalization just to reduce no of columns > > > In fact much of the point of > > http://blog.languager.org/2012/10/layout-imperative-in-functional.html > > is just this: that as code becomes more and more data-ish, > > a more-lines-less-columns regime becomes correspondingly irksome. > > I draw the opposite conclusion. The more your code is > laid out like a table, the more important it is to be > able to see the whole width of it at once. > > Your Haskell lexer example looks all very nice in a > good wide browser window. But reduce it so you can only > see half of it at a time and then tell me how readable > it is. Horrible. So what are we (if at all) disagreeing on?
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2016-04-17 14:01 +0300 |
| Message-ID | <877ffw5wjo.fsf@elektro.pacujo.net> |
| In reply to | #107154 |
Rustom Mody <rustompmody@gmail.com>:
> On Saturday, April 16, 2016 at 10:22:10 PM UTC+5:30, Marko Rauhamaa wrote:
>> A max line length of 79 characters is among the *only* rigorous
>> principles I judge coding style on.
>>
>> It comes with the maxim that one function must be visible at once on the
>> screen.
>
> Thats a strange self-contradiction.
Why? You are allowed to break a function into subfunctions, you know.
In fact, if you find yourself introducing coding "paragraphs" with
comments:
def f(...):
# I'll start by doing this
...
# segueing into the middle portion
...
# and finish it off as follows
...
you had better break those paragraphs off into separate functions. Just
turn your comments into function names.
Marko
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-04-17 21:14 +1000 |
| Message-ID | <mailman.98.1460891685.6324.python-list@python.org> |
| In reply to | #107169 |
On Sun, Apr 17, 2016 at 9:01 PM, Marko Rauhamaa <marko@pacujo.net> wrote: > In fact, if you find yourself introducing coding "paragraphs" with > comments: > > def f(...): > # I'll start by doing this > ... > # segueing into the middle portion > ... > # and finish it off as follows > ... > > you had better break those paragraphs off into separate functions. Just > turn your comments into function names. It's really easy to do this in toy examples, isn't it? But the real world is not so wonderful, as Alice's nanny said. What more often happens is that, once the function exceeds the stipulated maximum, it gets split somewhat arbitrarily into a "master" function and several "part" functions, with each part having exactly one call site in the driver and exactly none elsewhere. Even if the partial functions have reasonable names (which they don't always), they're still tightly bound to the master, and end up still functioning as a single unit. Unless you can genuinely make that subfunction useful in some other context, there's not a lot of use splitting it into a function. You don't generally see those perfect "paragraphs" in real-world code. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-04-17 13:04 +0100 |
| Message-ID | <nevttf$c5a$1@dont-email.me> |
| In reply to | #107170 |
On 17/04/2016 12:14, Chris Angelico wrote: > On Sun, Apr 17, 2016 at 9:01 PM, Marko Rauhamaa <marko@pacujo.net> wrote: >> In fact, if you find yourself introducing coding "paragraphs" with >> comments: >> >> def f(...): >> # I'll start by doing this >> ... >> # segueing into the middle portion >> ... >> # and finish it off as follows >> ... >> >> you had better break those paragraphs off into separate functions. Just >> turn your comments into function names. > > It's really easy to do this in toy examples, isn't it? But the real > world is not so wonderful, as Alice's nanny said. What more often > happens is that, once the function exceeds the stipulated maximum, it > gets split somewhat arbitrarily into a "master" function and several > "part" functions, with each part having exactly one call site in the > driver and exactly none elsewhere. Even if the partial functions have > reasonable names (which they don't always), they're still tightly > bound to the master, and end up still functioning as a single unit. > > Unless you can genuinely make that subfunction useful in some other > context, there's not a lot of use splitting it into a function. You > don't generally see those perfect "paragraphs" in real-world code. With the additional problems that the sub-functions need a way of accessing the local and declared names of the 'master' function. That means creating an interface (possibly a custom one for each sub-function) so that the master's local variables can be shared. Except that a sub-function can't directly write to the local variables that would be simply shared in the original monolithic function. Besides, for a set of sub-functions that are only used by a master function F, they really belong as local functions in F. That makes it even bigger and more complex, although access to F's locals is simplified. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2016-04-17 15:10 +0300 |
| Message-ID | <8737qk5tcm.fsf@elektro.pacujo.net> |
| In reply to | #107170 |
Chris Angelico <rosuav@gmail.com>: > On Sun, Apr 17, 2016 at 9:01 PM, Marko Rauhamaa <marko@pacujo.net> wrote: >> In fact, if you find yourself introducing coding "paragraphs" with >> comments: >> >> def f(...): >> # I'll start by doing this >> ... >> # segueing into the middle portion >> ... >> # and finish it off as follows >> ... >> >> you had better break those paragraphs off into separate functions. Just >> turn your comments into function names. > > It's really easy to do this in toy examples, isn't it? But the real > world is not so wonderful, as Alice's nanny said. I do this in the real world, professionally. Been doing it for decades, and it hasn't failed me so far. Exceptions exist, but they are that: rare exceptions. > What more often happens is that, once the function exceeds the > stipulated maximum, it gets split somewhat arbitrarily into a "master" > function and several "part" functions, with each part having exactly > one call site in the driver and exactly none elsewhere. Even if the > partial functions have reasonable names (which they don't always), > they're still tightly bound to the master, and end up still > functioning as a single unit. And? That's a feature, not a bug. It makes you analyze your approach a bit more. It makes you give names to things. It makes it more likely that your solution really works. And the main thing: whoever needs to come and maintain your code will have an easier time understanding what your code is trying to accomplish. > Unless you can genuinely make that subfunction useful in some other > context, there's not a lot of use splitting it into a function. You > don't generally see those perfect "paragraphs" in real-world code. No, that's Software Engineering 101: you split your solution into subroutines regardless of whether those subroutines are needed in multiple places. (The main practical problem with the divide-and-conquer approach is the fact that you need to drag the context around. Sometimes you have to keep piling on function arguments, which spoil the visual advantages you are trying to gain by partitioning your solution. One obvious solution to the argument clutter is to carry the context in *the* object or *a* special-purpose context object.) The compactness requirement for the code discourages empty lines and commenting. If find that, too, a feature rather than a bug. The code should in general speak for itself. Well-chosen names and a compact, elegant structure communicate the intent of the code better than plain-English comments that will not stay current with the code anyway. Marko
[toc] | [prev] | [next] | [standalone]
| From | Ben Finney <ben+python@benfinney.id.au> |
|---|---|
| Date | 2016-04-18 08:13 +1000 |
| Message-ID | <mailman.119.1460931251.6324.python-list@python.org> |
| In reply to | #107172 |
Marko Rauhamaa <marko@pacujo.net> writes: > Chris Angelico <rosuav@gmail.com>: > > > What more often happens is that, once the function exceeds the > > stipulated maximum, it gets split somewhat arbitrarily into a > > "master" function and several "part" functions, with each part > > having exactly one call site in the driver and exactly none > > elsewhere. Even if the partial functions have reasonable names > > (which they don't always), they're still tightly bound to the > > master, and end up still functioning as a single unit. > > And? That's a feature, not a bug. It makes you analyze your approach a > bit more. It makes you give names to things. It makes it more likely > that your solution really works. Yes. It also counters the tendency to let distant areas of code in a function become too tightly dependent. By identifying large functions with inherent “do this then do that then do the other then …” structure as a problem in itself, the writer must split it into small functions and think *explicitly* about how those parts interact. The interface between those parts is already part of the code design, and if they're tightly coupled in a way difficult to describe simply, it is a *bad* design already. A large function just obscures that, it doesn't make it better. Encouraging the split of large functions into small ones makes that design explicit, and exposes places wehre the coupling is too complex or too tight. The code writer is then explicitly and routinely thinking about how best to narrow the coupling between the parts. > > Unless you can genuinely make that subfunction useful in some other > > context, there's not a lot of use splitting it into a function. You > > don't generally see those perfect "paragraphs" in real-world code. The point of splitting functions is not re-use (though that is a useful side effect when it happens). The point is, in the face of trends that are all toward code becoming difficult to understand and tangled, to make the design as clear and simple and obviously correct as feasible. -- \ “Welchen Teil von ‘Gestalt’ verstehen Sie nicht? [What part of | `\ ‘gestalt’ don't you understand?]” —Karsten M. Self | _o__) | Ben Finney
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-04-18 11:57 +1000 |
| Message-ID | <57143eee$0$1612$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #107169 |
On Sun, 17 Apr 2016 09:01 pm, Marko Rauhamaa wrote:
> In fact, if you find yourself introducing coding "paragraphs" with
> comments:
>
> def f(...):
> # I'll start by doing this
> ...
> # segueing into the middle portion
> ...
> # and finish it off as follows
> ...
>
> you had better break those paragraphs off into separate functions. Just
> turn your comments into function names.
I'm reminded of the book "Refactoring - Ruby Edition" by Jay Fields, Shane
Harvie and Martin Fowler (which I strongly recommend, for what it's worth).
It is full of sections like:
Change Value to Reference
Change Reference to Value
Decompose Conditional
Recompose Conditional
and most relevant to this discussion:
Extract Method
Inline Method
(For "Method", substitute "Function".)
The intro to Extract Method says:
"You have a code fragment that can be grouped together."
and then the author explains that he looks for methods which are too long,
or code that needs a comment to explain what it does, and turns that
fragment of code into its own method.
But then the same author goes on to introduce Inline Method:
"A method's body is just as clear as its name."
and explains "sometimes you do come across a method in which the body is as
clear as the name. ... When this happens, you should then get rid of the
method. Indirection can be helpful, but needless indirection is
irritating."
Indeed.
Once your code is the most straight-forward and simple implementation of the
needed algorithm, it is hard to reduce complexity any further. All you can
do is move the complexity around. You can hide the complexity inside the
function, where it exposes itself only to those who need to dig into the
body of the function to understand what it does.
Or you can extract the code into functions of their own, which decreases the
internal complexity of the function, but increases the complexity of the
application or module.
Extract Method hides complexity of the function by moving it into the
module:
def Do_The_Thing():
...
def internal_subpart_start(): ...
def internal_subpart_middle(): ...
def internal_subpart_end(): ...
Inline Method reduces module complexity by moving it into the function:
def Do_The_Thing():
... # internal subpart start
... # internal subpart middle
... # internal subpart end
But the total complexity remains the same.
One technique which is common in Pascal, but less so in Python, is to get
the best of both worlds by using nested functions. In Python syntax:
def Do_The_Thing():
def internal_subpart_start(): ...
def internal_subpart_middle(): ...
def internal_subpart_end(): ...
...
This hides complexity of the function by moving it into the nested
functions, where they can be ignored, but without increasing the complexity
of the module. (Of course, the *total* complexity of module, function and
nested functions is the same.)
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2016-04-18 11:02 +0300 |
| Message-ID | <87ega3s5sv.fsf@elektro.pacujo.net> |
| In reply to | #107219 |
Steven D'Aprano <steve@pearwood.info>: > One technique which is common in Pascal, but less so in Python, is to get > the best of both worlds by using nested functions. In Python syntax: > > def Do_The_Thing(): > def internal_subpart_start(): ... > def internal_subpart_middle(): ... > def internal_subpart_end(): ... > ... That really should be done more. C weaned us from the routine Pascal mechanism, but there's no reason not to exploit it again in Python. It also solves the problem of lugging the local context between internal functions, especially now that Python possesses the "nonlocal" keyword. Marko
[toc] | [prev] | [next] | [standalone]
| From | Gregory Ewing <greg.ewing@canterbury.ac.nz> |
|---|---|
| Date | 2016-04-18 20:43 +1200 |
| Message-ID | <dnjl1rFu1i0U1@mid.individual.net> |
| In reply to | #107253 |
Marko Rauhamaa wrote: > Steven D'Aprano <steve@pearwood.info>: > >>def Do_The_Thing(): >> def internal_subpart_start(): ... >> def internal_subpart_middle(): ... >> def internal_subpart_end(): ... >> ... > > That really should be done more. C weaned us from the routine Pascal > mechanism, but there's no reason not to exploit it again in Python. Two things Python has that Pascal didn't are modules and classes. They take care of a lot of the grouping that you had to rely on nested functions for in Pascal. I do find myself nesting functions like that in Python, but only very occasionally. -- Greg
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2016-04-18 12:17 +0300 |
| Message-ID | <874mazs2ca.fsf@elektro.pacujo.net> |
| In reply to | #107255 |
Gregory Ewing <greg.ewing@canterbury.ac.nz>: > Marko Rauhamaa wrote: >> Steven D'Aprano <steve@pearwood.info>: >> >>>def Do_The_Thing(): >>> def internal_subpart_start(): ... >>> def internal_subpart_middle(): ... >>> def internal_subpart_end(): ... >>> ... >> >> That really should be done more. C weaned us from the routine Pascal >> mechanism, but there's no reason not to exploit it again in Python. > > Two things Python has that Pascal didn't are modules and classes. They > take care of a lot of the grouping that you had to rely on nested > functions for in Pascal. I don't think Pascal did it for grouping or readability but for conceptual correctness. When I moved from Pascal to C, I felt the absence of local functions; it was a slight unease about abstraction leakage. > I do find myself nesting functions like that in Python, but only very > occasionally. Same for me. Essentially, I use local functions to register callbacks. Decades of C has done that to us. Marko
[toc] | [prev] | [next] | [standalone]
| From | eryk sun <eryksun@gmail.com> |
|---|---|
| Date | 2016-04-17 00:01 -0500 |
| Message-ID | <mailman.92.1460869339.6324.python-list@python.org> |
| In reply to | #107101 |
On Sat, Apr 16, 2016 at 8:30 PM, Tim Chase
<python.list@tim.thechases.com> wrote:
> On 2016-04-16 19:39, eryk sun wrote:
>> On Sat, Apr 16, 2016 at 4:50 PM, Tim Chase wrote:
>> > I also do some editing/diffing within a cmd.exe window on Windows
>> > which is limited to 80 characters unless you do some hijinks in
>> > the settings to expand it.
>>
>> Try `mode con cols=120 lines=30`.
>
> Yeah, that will do it, as will going into the settings and changing
> it. But basically every other program on Windows, and every console
> on Linux/BSD/Mac will let me resize a terminal running while another
> program is running. For a cmd.exe window, I have to quit, issue the
> `mode` command, restart my application, and return to where I was.
cmd.exe doesn't own a window. You probably meant the console
host/server, conhost.exe. cmd has handles for StandardInput,
StandardOutput, and StandardError -- which may be handles for console
I/O, but not necessarily.
I agree that the classic console window has a bad UI. It can only be
resized up to the size of the screen buffer, which is not terribly
useful. There's no way to change the screen buffer size when manually
sizing the window. You have to either use the properties dialog or the
API. In Python you can run mode.com via subprocess.call('mode.com con
cols=120'). Or you can use ctypes to call GetConsoleScreenBufferInfoEx
and SetConsoleScreenBufferInfoEx.
The Windows 10 console is a significant step in the right direction.
It automatically resizes the screen buffer with text wrapping, selects
a text stream instead of a rectangle, and uses regular keyboard
shortcuts such as Ctrl+C and Ctrl+V for copy and paste. It still has
room for improvement, however. It doesn't support fonts that mix
half-width and full-width glyphs. It can't display characters that use
multiple WCHAR values, such as astral characters (UTF-16 surrogate
pairs) and decomposed characters. It doesn't support ANSI/VT100
terminal emulation (but maybe this is in the works for the new Linux
subsystem).
[toc] | [prev] | [next] | [standalone]
| From | Random832 <random832@fastmail.com> |
|---|---|
| Date | 2016-04-17 01:10 -0400 |
| Message-ID | <mailman.93.1460869842.6324.python-list@python.org> |
| In reply to | #107101 |
On Sun, Apr 17, 2016, at 01:01, eryk sun wrote: > It doesn't support fonts that mix half-width and full-width glyphs. This is the most baffling bit to me. I mean, it _has_ to, for Chinese, Japanese, and Korean users. This support obviously exists in the code. Why not extend it to everyone, instead of maintaining two versions of whatever it's doing?
[toc] | [prev] | [next] | [standalone]
| From | eryk sun <eryksun@gmail.com> |
|---|---|
| Date | 2016-04-17 03:14 -0500 |
| Message-ID | <mailman.96.1460880938.6324.python-list@python.org> |
| In reply to | #107101 |
On Sun, Apr 17, 2016 at 12:10 AM, Random832 <random832@fastmail.com> wrote:
>
> On Sun, Apr 17, 2016, at 01:01, eryk sun wrote:
>> It doesn't support fonts that mix half-width and full-width glyphs.
>
> This is the most baffling bit to me. I mean, it _has_ to, for Chinese,
> Japanese, and Korean users. This support obviously exists in the code.
> Why not extend it to everyone, instead of maintaining two versions of
> whatever it's doing?
Right, the console implements this for CJK locales, in which case it
uses 2 columns for a full-width character. But based on the public
symbols, I'd guess that the implementation is tied to using a DBCS
codepage:
0:004> x /1 /n conhostv2!*dbcs*
ConhostV2!DBCS_SCREEN_BUFFER::CreateInstance
ConhostV2!DBCS_SCREEN_BUFFER::`scalar deleting destructor'
ConhostV2!DBCS_SCREEN_BUFFER::~DBCS_SCREEN_BUFFER
ConhostV2!InitializeDbcsMisc
ConhostV2!IsDBCSLeadByteConsole
ConhostV2!ReCreateDbcsScreenBuffer
ConhostV2!ReCreateDbcsScreenBufferWorker
ConhostV2!RemoveDbcsMark
ConhostV2!RemoveDbcsMarkAll
ConhostV2!RemoveDbcsMarkCell
ConhostV2!g_fIsDBCSACP
Implementing this in a Western locale would need an implementation
based on Unicode character properties.
[toc] | [prev] | [next] | [standalone]
| From | Dennis Lee Bieber <wlfraed@ix.netcom.com> |
|---|---|
| Date | 2016-04-17 12:13 -0400 |
| Message-ID | <mailman.102.1460909615.6324.python-list@python.org> |
| In reply to | #107101 |
On Sat, 16 Apr 2016 21:59:01 -0400, Random832 <random832@fastmail.com>
declaimed the following:
>
>I heard Windows 10 is going to finally fix this, anyway.
Probably by removing the old CLI window completely and making everyone
learn PowerShell ISE
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/
[toc] | [prev] | [next] | [standalone]
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.python
csiph-web