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

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

Re: PEP8 79 char max

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: PEP8 79 char max Devyn Collier Johnson <devyncjohnson@gmail.com> - 2013-07-29 16:24 -0400
    Re: PEP8 79 char max Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-07-29 21:42 +0000
      Re: PEP8 79 char max Devyn Collier Johnson <devyncjohnson@gmail.com> - 2013-07-29 18:30 -0400
      Re: PEP8 79 char max Ed Leafe <ed@leafe.com> - 2013-07-29 17:54 -0500
      Re: PEP8 79 char max Vito De Tullio <vito.detullio@gmail.com> - 2013-07-30 19:08 +0200
      Re: PEP8 79 char max Joshua Landau <joshua@landau.ws> - 2013-07-30 18:42 +0100
        Re: PEP8 79 char max Grant Edwards <invalid@invalid.invalid> - 2013-07-30 17:52 +0000
          Re: PEP8 79 char max Joshua Landau <joshua@landau.ws> - 2013-07-31 07:16 +0100
          Re: PEP8 79 char max Tim Chase <python.list@tim.thechases.com> - 2013-07-31 05:56 -0500
            Re: PEP8 79 char max Neil Cerutti <neilc@norwich.edu> - 2013-07-31 13:02 +0000
              Re: PEP8 79 char max Grant Edwards <invalid@invalid.invalid> - 2013-07-31 16:35 +0000
                Re: PEP8 79 char max Marcelo MD <lists.md@gmail.com> - 2013-07-31 14:45 -0300
                  Re: PEP8 79 char max Neil Cerutti <neilc@norwich.edu> - 2013-07-31 17:59 +0000
                    Re: PEP8 79 char max Grant Edwards <invalid@invalid.invalid> - 2013-07-31 18:16 +0000
                      Re: PEP8 79 char max Neil Cerutti <neilc@norwich.edu> - 2013-07-31 18:37 +0000
                        Re: PEP8 79 char max Grant Edwards <invalid@invalid.invalid> - 2013-07-31 18:56 +0000
                          Re: PEP8 79 char max Neil Cerutti <neilc@norwich.edu> - 2013-07-31 19:25 +0000
                      RE: PEP8 79 char max "Prasad, Ramit" <ramit.prasad@jpmorgan.com.dmarc.invalid> - 2013-07-31 18:33 +0000
                Re: PEP8 79 char max Skip Montanaro <skip@pobox.com> - 2013-07-31 13:05 -0500
            Re: PEP8 79 char max Grant Edwards <invalid@invalid.invalid> - 2013-07-31 16:32 +0000
              Re: PEP8 79 char max Tim Chase <python.list@tim.thechases.com> - 2013-07-31 13:19 -0500
              Re: PEP8 79 char max Tim Chase <python.list@tim.thechases.com> - 2013-07-31 13:24 -0500
              Re: PEP8 79 char max Joshua Landau <joshua@landau.ws> - 2013-08-01 18:21 +0100
                Re: PEP8 79 char max Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-08-01 19:03 +0000
                Re: PEP8 79 char max Grant Edwards <invalid@invalid.invalid> - 2013-08-01 19:29 +0000
                  Re: PEP8 79 char max Grant Edwards <invalid@invalid.invalid> - 2013-08-01 19:53 +0000
                  Re: PEP8 79 char max Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-08-01 20:39 -0400
                    Re: PEP8 79 char max Grant Edwards <invalid@invalid.invalid> - 2013-08-02 13:58 +0000
          Re: PEP8 79 char max Wayne Werner <wayne@waynewerner.com> - 2013-08-03 06:23 -0500
            Re: PEP8 79 char max Metallicow <metaliobovinus@gmail.com> - 2013-09-05 15:21 -0700
              Re: PEP8 79 char max Terry Reedy <tjreedy@udel.edu> - 2013-09-05 21:47 -0400
                Re: PEP8 79 char max Metallicow <metaliobovinus@gmail.com> - 2013-09-05 19:59 -0700
                  Re: PEP8 79 char max Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-09-06 04:01 +0000
                    Re: PEP8 79 char max Metallicow <metaliobovinus@gmail.com> - 2013-09-05 21:21 -0700
                    Re: PEP8 79 char max Metallicow <metaliobovinus@gmail.com> - 2013-09-06 06:34 -0700
                      Re: PEP8 79 char max Metallicow <metaliobovinus@gmail.com> - 2013-09-06 09:07 -0700
                  Re: PEP8 79 char max Skip Montanaro <skip@pobox.com> - 2013-09-06 05:09 -0500
                  Re: PEP8 79 char max Tim Chase <python.list@tim.thechases.com> - 2013-09-06 05:35 -0500
                  Re: PEP8 79 char max Tim Delaney <timothy.c.delaney@gmail.com> - 2013-09-06 20:47 +1000
                    Re: PEP8 79 char max Metallicow <metaliobovinus@gmail.com> - 2013-09-06 05:24 -0700
                      Re: PEP8 79 char max Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-09-06 19:22 -0400
                  Re: PEP8 79 char max Tim Chase <python.list@tim.thechases.com> - 2013-09-06 07:56 -0500
                    Re: PEP8 79 char max Neil Cerutti <neilc@norwich.edu> - 2013-09-06 13:12 +0000
              Re: PEP8 79 char max Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-09-06 03:40 +0000
                Re: PEP8 79 char max Metallicow <metaliobovinus@gmail.com> - 2013-09-05 21:19 -0700
                Re: PEP8 79 char max Serhiy Storchaka <storchaka@gmail.com> - 2013-09-07 21:00 +0300
      Re: PEP8 79 char max Vito De Tullio <vito.detullio@gmail.com> - 2013-07-30 20:00 +0200

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

#53813

On Fri, 6 Sep 2013 05:24:42 -0700 (PDT), Metallicow
<metaliobovinus@gmail.com> declaimed the following:

>
>RailRoadTieWidth = 79.1234567890
>
>>>> 79 = 'Width Of A Horse"s Ass'
>  File "<input>", line 1
>SyntaxError: can't assign to literal
>
>>>>RailRoadTieWidth.attribute
>("American", "Steam")
>
>>>>79.attribute = ("Roman", "Chariot")
>  File "<input>", line 1
>    79.attribute = ("Roman", "Chariot")
>               ^
>SyntaxError: invalid syntax
>
	You missed one...

>>> 79 .attribute=("Roman", "Chariot")
Traceback (most recent call last):
  File "<interactive input>", line 1, in <module>
AttributeError: 'int' object has no attribute 'attribute'
>>> 

	79.attribute	starts off looking like a floating point value, and
chokes on the non-decimal digit "a"...

	79 .attribute	starts off as an integer and an attribute access.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#53783

On 2013-09-06 20:47, Tim Delaney wrote:
> On 6 September 2013 20:35, Tim Chase wrote:
> > I'm just glad it's no longer 40-chars-per-column and purely
> > upper-case like the Apple ][+ on which I cut my programming teeth.
> 
> Couldn't you switch the ][+ into high-res mode? You could with the
> IIe. Made programming in DOS 3.3 BASIC so much nicer.

There was an 80-column add-on card that also supported lower-case
(though, IIRC, you also had to do a hardware hack to wire the <shift>
key to the joystick button to get it to be recognized in certain
cases).  The IIe was a far better machine, having the 80-column card
built in.  PR#3 :-)

I'm also glad Python doesn't require prefixing lines with
line-numbers for GOTO/GOSUB purposes, then requiring external
the line-renumbering utilities that AppleSoft BASIC required :-S

-tkc

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

#53784

On 2013-09-06, Tim Chase <python.list@tim.thechases.com> wrote:
> On 2013-09-06 20:47, Tim Delaney wrote:
>> On 6 September 2013 20:35, Tim Chase wrote:
>> > I'm just glad it's no longer 40-chars-per-column and purely
>> > upper-case like the Apple ][+ on which I cut my programming
>> > teeth.
>> 
>> Couldn't you switch the ][+ into high-res mode? You could with
>> the IIe. Made programming in DOS 3.3 BASIC so much nicer.
>
> There was an 80-column add-on card that also supported
> lower-case (though, IIRC, you also had to do a hardware hack to
> wire the <shift> key to the joystick button to get it to be
> recognized in certain cases).  The IIe was a far better
> machine, having the 80-column card built in.  PR#3 :-)
>
> I'm also glad Python doesn't require prefixing lines with
> line-numbers for GOTO/GOSUB purposes, then requiring external
> the line-renumbering utilities that AppleSoft BASIC required
> :-S

Though its graphics and sound were far inferior, as a C64 user I
was really jealous of the speed of the built-in Apple disk
drives. The only programming I did on them was typing in some of
the programs from "Compute!", back before it converted format to
C64 only. Anybody care for a game of Laserchess?

-- 
Neil Cerutti

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

#53756

On Thu, 05 Sep 2013 15:21:28 -0700, Metallicow wrote:

> Well as for my opinion, it is more closer to the truth than others
> because... Experience:
> 1. I know Python and have read the PEP8. 2. I have knowledge of/worked
> with the Printing Trades. 3. Grandfather owned/operated own Printshop
> for 40+yrs. Which I also worked in at one point.

Thanks for the comments, and welcome, but I really don't have a clue what 
the relevance of most of them are.


> If you are still using equipment that requires 79, then chances are you
> have/will already gone out of business or are keeping/using said
> equipment for nostalgic purposes.

The point is not that there is *equipment* that requires 79 characters 
per line, but that *reading text* is better with a maximum line length 
closer to 79 characters than (say) 140 characters. I've just randomly 
picked up a magazine (less than 50 characters per line) and two books (60 
and 82 characters per line respectively).

The exact max line length picked is not, in and of itself, critical. PEP 
8 could have picked 60 characters, or 72, or 77, or 82. 79 characters 
(plus newline) happens to be a better choice than (say) 77 or 82 for 
historical reasons: some *old* computer equipment was limited to 79 
characters (plus newline), and consequently some *new* computer software 
expects the same convention to be held.

In a sense, it's a bit like the old urban legend about the width of the 
Space Shuttle booster rockets being determined by the width of ancient 
Roman chariots.

http://www.snopes.com/history/american/gauge.asp

While the precise details are wrong, the general claim is more or less 
true for boring and unremarkable reasons.


> As far as math goes. 10 is a nice round number. So multiples of 10 are
> prefer. 80 being my personal choice for editing.

That gives you 80 visible characters plus newline = 81 characters in 
total. Quick, what's 81/7?

> Zen says: Simple is better than complex. Use a round number. Integer
> math is easier than float math for the majority of the population. Time
> yourself, not the interpreter with these three questions: In the face of
> ambiguity, refuse the temptation to guess. If it helps get out the old
> school pen and paper. Question1: 80/8
> Question2: 79/8

I don't see the point of this. Why divide by 8? What is this supposed to 
demonstrate?

Also, you're tossing around koans from a Zen that are irrelevant. 79 or 
80, both are equally simple. Where is the ambiguity? The reader might be 
forgiven for thinking you're trying to dazzle them and pull the wool over 
their eyes by tossing out references to the Zen that sound good but have 
no relevance to the question being discussed.


> Question3: How many chars does you calculator(real or virtual) support?

Seven. Are you suggesting that we should limit our code to a maximum of 
seven characters per line? If not, I don't see the point of your question.


> Zen says: Special cases aren't special enough to break the rules. PEP8
> isn't a rule. Rules are defined by the equipment/device developers.

PEP 8 certainly is a collection of rules. They are mandatory for new code 
added to the standard library, and optional but recommended for third 
party libraries.


> Ask yourself... How often do you actually use these 79char devices?

My brain is better at reading lines with maximum line length of 79 
characters than 140 characters. How often do I use my brain? At least 
once a day.


[...]
> Zen says:
> Although practicality beats purity.
> Errors should never pass silently.
> Unless explicitly silenced.

And yet, a bird in the hand saves nine, and the early bird bells the cat.


> PEP8 would have been better to define various numbers for realworld
> types of equipment/devices based on average general type of
> equipment/device specs.

No it would not. That would be silly.


> Closing Zen:
> If the implementation is hard to explain, it's a bad idea. If the
> implementation is easy to explain, it may be a good idea.

The implementation is easy to explain: stop typing before you reach 79 
characters, and start a new line of code.


> Yep, that's my nuts and bolts on the issue. Walk into you local
> Printshop and ask them about this stuff. Then on your way out the door,
> ask for a business card and see how many chars are on that also. Beware:
> You might actually learn something about advertising while you are there
> also. :)

I don't need to ask them for a business card, since I have a nice 
collection of them. Most of them have < 40 characters per line. A few 
have < 60 characters on the longest line. None of them come even close to 
79 characters per line.

What's your point? That we should limit ourselves to code that fits on a 
business card?



-- 
Steven

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

#53760

On Thursday, September 5, 2013 10:40:46 PM UTC-5, Steven D'Aprano wrote:
> Thanks for the comments, and welcome, but I really don't have a clue what 
> the relevance of most of them are.
Real-world Experience.
> > If you are still using equipment that requires 79, then chances are you
> > have/will already gone out of business or are keeping/using said
> > equipment for nostalgic purposes.
> 
> The point is not that there is *equipment* that requires 79 characters 
> per line, but that *reading text* is better with a maximum line length 
> closer to 79 characters than (say) 140 characters. I've just randomly 
> picked up a magazine (less than 50 characters per line) and two books (60 
> and 82 characters per line respectively).
The argument I am suggesting is 79 vs 80.
> The exact max line length picked is not, in and of itself, critical. PEP 
> 
> 8 could have picked 60 characters, or 72, or 77, or 82. 79 characters 
> (plus newline) happens to be a better choice than (say) 77 or 82 for 
> historical reasons: some *old* computer equipment was limited to 79 
> characters (plus newline), and consequently some *new* computer software 
> expects the same convention to be held.
I propose 80 for Zen: Simplicity.
> In a sense, it's a bit like the old urban legend about the width of the 
> Space Shuttle booster rockets being determined by the width of ancient 
> Roman chariots.
Haha. *Gets a Laugh*
> http://www.snopes.com/history/american/gauge.asp
> 
> While the precise details are wrong, the general claim is more or less 
> true for boring and unremarkable reasons.
Ok.
> > As far as math goes. 10 is a nice round number. So multiples of 10 are
> > prefer. 80 being my personal choice for editing.
> That gives you 80 visible characters plus newline = 81 characters in 
> total. Quick, what's 81/7?
We are focusing on end-users, which might be simple minded. Simple is better than complex.
> > Zen says: Simple is better than complex. Use a round number. Integer
> > math is easier than float math for the majority of the population. Time
> > yourself, not the interpreter with these three questions: In the face of
> > ambiguity, refuse the temptation to guess. If it helps get out the old
> > school pen and paper. Question1: 80/8
> > Question2: 79/8
> I don't see the point of this. Why divide by 8? What is this supposed to 
> demonstrate?
Divide by any simple number is 0 simple enouch...?
> Also, you're tossing around koans from a Zen that are irrelevant. 79 or 
> 80, both are equally simple. Where is the ambiguity? The reader might be 
> forgiven for thinking you're trying to dazzle them and pull the wool over 
> their eyes by tossing out references to the Zen that sound good but have 
> no relevance to the question being discussed.
No., 79 and 80 are not equally simple. 79 is odd, and 80 is even.
> 
> > Question3: How many chars does you calculator(real or virtual) support?
> Seven. Are you suggesting that we should limit our code to a maximum of 
Ok. Mine displays ten. This question was to get most people off their duff and grab a piece of old-school tech. Might be solar in nature.
> seven characters per line? If not, I don't see the point of your question.
See above answer.
> > Zen says: Special cases aren't special enough to break the rules. PEP8
> > isn't a rule. Rules are defined by the equipment/device developers.
> PEP 8 certainly is a collection of rules. They are mandatory for new code 
> added to the standard library, and optional but recommended for third 
> party libraries.
What are the official rules, then... None...?
> > Ask yourself... How often do you actually use these 79char devices?
> My brain is better at reading lines with maximum line length of 79 
> characters than 140 characters. How often do I use my brain? At least 
> once a day.
> [...]
Ok. I prefer 80 remember. Simple. base 10.
> > Zen says:
> > Although practicality beats purity.
> > Errors should never pass silently.
> > Unless explicitly silenced.
> And yet, a bird in the hand saves nine, and the early bird bells the cat.
if python.notDefined():
    cats != birds != cats 
> > PEP8 would have been better to define various numbers for realworld
> > types of equipment/devices based on average general type of
> > equipment/device specs.
> No it would not. That would be silly.
Well... Why Not? What do you use?
> > Closing Zen:
> > If the implementation is hard to explain, it's a bad idea. If the
> > implementation is easy to explain, it may be a good idea.
> The implementation is easy to explain: stop typing before you reach 79 
> characters, and start a new line of code.
I believe Guido once worked for google, why doesn't the software reflect your preferences. Ask google, or him, not me.
> > Yep, that's my nuts and bolts on the issue. Walk into you local
> > Printshop and ask them about this stuff. Then on your way out the door,
> > ask for a business card and see how many chars are on that also. Beware:
> > You might actually learn something about advertising while you are there
> > also. :)
> I don't need to ask them for a business card, since I have a nice 
> collection of them. Most of them have < 40 characters per line. A few 
> have < 60 characters on the longest line. None of them come even close to 
> 79 characters per line.
> What's your point? That we should limit ourselves to code that fits on a 
> business card?
My grandfather once told me, "If you can put you resume on a business card, you will succeed in life."

My business card reads "Jack-of-all-trades\nMaster of one: That's my Trade Secret."

> -- 
> 
> Steven

Love these...
> 
> 
> 
> 
> 
> > provided by google.
> production time of post - >'s
Simplicity.

Thanks Again for comments/opinions. It teaches everyone.

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

#53826

06.09.13 06:40, Steven D'Aprano написав(ла):
> PEP 8 certainly is a collection of rules. They are mandatory for new code
> added to the standard library, and optional but recommended for third
> party libraries.

No. They are optional but recommended for new code added to the standard 
library, and indifferent for third party libraries.

But generally there are no much reasons to not obey PEP 8.

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

#51591

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

[toc] | [prev] | [standalone]

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

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

csiph-web