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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#51682

On 2013-07-31 16:32, Grant Edwards wrote:
> On 2013-07-31, Tim Chase <python.list@tim.thechases.com> wrote:
> > 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)
> 
> Exactly.  When you have more than about 5 columns and 10 rows,
> having things aligned makes it far, far, easier to maintain.

As mentioned by Marcelo, when they can vary in length, maintaining is
a pain.  Even if your editor supports aligning (like vim with Dr.
Chip's align.vim plugin).  If I have a table of greater dimensions, I
tend to refactor into a more readable+maintainable scheme, whether
using dicts or named tuples and then break out the rows onto their own
lines:

  from collections import namedtuple
  Descriptor = namedtuple("Descriptor", ["name", "value",
  "description"])
  for name, value, description in (
      Descriptor(
        name="cost",
        value=42,
        description="How much it cost",
        ),
      Descriptor(
        name="status",
        value=3141,
        description="Status code from ISO-3.14159",
        ),
      ):
    do_something(name, value)
    print(description)

Using a namedtuple, if you forget one of the fields (or add an
extra, or misspell one), it yells at you:

  TypeError: __new__() takes exactly 4 arguments (2 given)
  TypeError: __new__() takes exactly 4 arguments (6 given)
  TypeError: __new__() got an unexpected keyword argument 'nmae'

There is redundancy of the kwarg params, but this can be skipped
if you prefer DRY code to more readable code.

Doing this also has the benefit that, when diffing, you don't get
noise when columns are merely adjusted visually.

-tkc

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

#51684

On 2013-07-31 16:32, Grant Edwards wrote:
> On 2013-07-31, Tim Chase <python.list@tim.thechases.com> wrote:  
> > 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)  
> 
> Exactly.  When you have more than about 5 columns and 10 rows,
> having things aligned makes it far, far, easier to maintain.  

As mentioned by Marcelo, when they can vary in length, maintaining is
a pain.  Even if your editor supports aligning (like vim with Dr.
Chip's align.vim plugin).  If I have a table of greater dimensions, I
tend to refactor into a more readable+maintainable scheme, whether
using dicts or named tuples and then break out the rows onto their own
lines:

  from collections import namedtuple
  Descriptor = namedtuple("Descriptor", ["name", "value", "description"])
  for name, value, description in (
      Descriptor(
        name="cost",
        value=42,
        description="How much it cost",
        ),
      Descriptor(
        name="status",
        value=3141,
        description="Status code from ISO-3.14159",
        ),
      ):
    do_something(name, value)
    print(description)

Using a namedtuple, if you forget one of the fields (or add an
extra, or misspell one), it yells at you:

  TypeError: __new__() takes exactly 4 arguments (2 given)
  TypeError: __new__() takes exactly 4 arguments (6 given)
  TypeError: __new__() got an unexpected keyword argument 'nmae'

There is redundancy of the kwarg params, but this can be skipped
if you prefer DRY code to more readable code.

Doing this also has the benefit that, when diffing, you don't get
noise when columns are merely adjusted visually.

-tkc

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

#51743

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

On 31 July 2013 17:32, Grant Edwards <invalid@invalid.invalid> wrote:

> On 2013-07-31, Tim Chase <python.list@tim.thechases.com> wrote:
> > 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?
>
> For example: if you're writing an assembler, you usually have a table
> of mnemonics/opcodes/instruction-format/addressing-modes.


Why are you writing an assembler?


>  > 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)
>
> Exactly.  When you have more than about 5 columns and 10 rows, having
> things aligned makes it far, far, easier to maintain.


Honestly I've never had to do something like this. If it got that large,
though, I'd factor it out into it's own file and possibly take the advice
from others on this list by making it a CSV.

That said for someone like me the very tiny frequency I'd have to do such a
thing would pale in comparison to the other costs and benefits of variable
with fonts.


>  > which does give some modest readability benefits, but at a creation
> > cost I personally am unwilling to pay.
>
> It only gets typed once, it gets read hundreds or thousands of times.
> Optimize the common case.
>

PEP 8, under the things-not-to-do section, says:

    · More than one space around an assignment (or other) operator to align
it with another.

    Yes:
        x = 1
        y = 2
        long_variable = 3

    No:
        x             = 1
        y             = 2
        long_variable = 3

I assume similar applies here. Obviously PEP 8 isn't a rule but it's a
rough stab at general consensus.

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

#51755

On Thu, 01 Aug 2013 18:21:32 +0100, Joshua Landau wrote:

> On 31 July 2013 17:32, Grant Edwards <invalid@invalid.invalid> wrote:
> 
>> On 2013-07-31, Tim Chase <python.list@tim.thechases.com> wrote:
>> > 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?
>>
>> For example: if you're writing an assembler, you usually have a table
>> of mnemonics/opcodes/instruction-format/addressing-modes.
> 
> 
> Why are you writing an assembler?


Maybe he's (re-)creating PyPy :-)


-- 
Steven

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

#51758

On 2013-08-01, Joshua Landau <joshua@landau.ws> wrote:
> On 31 July 2013 17:32, Grant Edwards <invalid@invalid.invalid> wrote:
>
>> On 2013-07-31, Tim Chase <python.list@tim.thechases.com> wrote:
>> > 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?
>>
>> For example: if you're writing an assembler, you usually have a table
>> of mnemonics/opcodes/instruction-format/addressing-modes.
>
> Why are you writing an assembler?

I got tired of hand assembling (and disassembling) code for a custom
microprocessor, so I wrote an assembler and a disassembler.

-- 
Grant Edwards               grant.b.edwards        Yow! I smell like a wet
                                  at               reducing clinic on Columbus
                              gmail.com            Day!

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

#51762

On 2013-08-01, Grant Edwards <invalid@invalid.invalid> wrote:
> On 2013-08-01, Joshua Landau <joshua@landau.ws> wrote:
>> On 31 July 2013 17:32, Grant Edwards <invalid@invalid.invalid> wrote:
>>
>>> On 2013-07-31, Tim Chase <python.list@tim.thechases.com> wrote:
>>> > 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?
>>>
>>> For example: if you're writing an assembler, you usually have a table
>>> of mnemonics/opcodes/instruction-format/addressing-modes.
>>
>> Why are you writing an assembler?
>
> I got tired of hand assembling (and disassembling) code for a custom
> microprocessor, so I wrote an assembler and a disassembler.

FWIW, 250 lines of Python gets you a pretty decent 2-pass absolute
assembler with full arithmetic expression support (including
user-defined symbols).  That 250 lines includes the "table" that
defines the individual instructions.  

And yes, the columns in that table are aligned using spaces. ;)

-- 
Grant Edwards               grant.b.edwards        Yow! I just had a NOSE
                                  at               JOB!!
                              gmail.com            

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

#51772

On Thu, 1 Aug 2013 19:29:06 +0000 (UTC), Grant Edwards
<invalid@invalid.invalid> declaimed the following:

>
>I got tired of hand assembling (and disassembling) code for a custom
>microprocessor, so I wrote an assembler and a disassembler.

	Let me know when you recreate XDS meta-symbol. It didn't even have the
Sigma native instruction set built in, one had to specify the instruction
set using a "system" directive. What it did have was a directive to define
instruction formats (my manuals are in storage so this is pseudo-code).

MOV	opt,2,3,3	b'01',af(1),af(2)

Which translates as: mnemonic is MOV, format is 2-bits, 3-bits, 3-bits,
first field is binary 01, second field is argument field 1, third field is
argument field 2. Granted, the Sigma was a 32-bit machine, but one could
create an absolute image cross assembler by just defining a bunch of the
above. I forget the opcode for the 8080, but that line would define the
8080 MOV instruction (given that one had defined numeric values for the
register symbols...

	MOV	A,D

parameters could come from label, command, or argument field

MOV	opt,2,3,3	b'01',cf(2),af(1)

would change the source syntax to 

	MOV,A		D

and for insanity

MOV	opt,2,3,3	b'01',lf(2),af(1)

would give

,A	MOV	D


-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#51811

On 2013-08-02, Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:
> On Thu, 1 Aug 2013 19:29:06 +0000 (UTC), Grant Edwards
><invalid@invalid.invalid> declaimed the following:
>
>>
>>I got tired of hand assembling (and disassembling) code for a custom
>>microprocessor, so I wrote an assembler and a disassembler.
>
> 	Let me know when you recreate XDS meta-symbol. It didn't even have the
> Sigma native instruction set built in, one had to specify the instruction
> set using a "system" directive. What it did have was a directive to define
> instruction formats (my manuals are in storage so this is pseudo-code).
>
> MOV	opt,2,3,3	b'01',af(1),af(2)
>
> Which translates as: mnemonic is MOV, format is 2-bits, 3-bits, 3-bits,
> first field is binary 01, second field is argument field 1, third field is
> argument field 2.

That's pretty much how my assembler works.  There is one variable
bit-width operand field in the opcode byte, and some instructions have
a single byte immediate operand following the opcode byte.  Operands
can eitehr be absolute values or PC-relative offsets (in the case of
branch instructions).

-- 
Grant Edwards               grant.b.edwards        Yow! I hope the
                                  at               ``Eurythmics'' practice
                              gmail.com            birth control ...

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

#51853

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

On Wed, 31 Jul 2013, Joshua Landau wrote:
> 
> To explain, I tend to take the "HTML" form of alignment by wrapping:
> 
> open stuff stuff stuff close
> 
> to
> 
> open
>     stuff
>     stuff
>     stuff
> close

Depending on how much 'stuff' I have, I, for one, prefer a third:

open stuff
      stuff
      stuff
     close


Which then makes it 1) fairly easy to read, 2) fairly easy to extend.

Of course it could just be that I'm used to that style - our brains are 
wired weird.


-W

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

#53742

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.

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.

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

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
Question3: How many chars does you calculator(real or virtual) support?


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.

Ask yourself... How often do you actually use these 79char devices?
Of course it is understandable for something small that can fit in your pocket might have less. For Example a smartphone.

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

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

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.

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.
:) 

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

#53749

On 9/5/2013 6:21 PM, Metallicow wrote:
>
> 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.
>
> As far as math goes. 10 is a nice round number.

79 chars + 1 cursor (or \n) == 80, the nice round number.

Anyway, it is just a guideline. Ignore it if you wish.

-- 
Terry Jan Reedy

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

#53751

On Thursday, September 5, 2013 8:47:01 PM UTC-5, Terry Reedy wrote:
> On 9/5/2013 6:21 PM, Metallicow wrote:
> 
> >
> 
> > 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.
> 
> >
> 
> > As far as math goes. 10 is a nice round number.
> 
> 
> 
> 79 chars + 1 cursor (or \n) == 80, the nice round number.
> 
> 
> 
> Anyway, it is just a guideline. Ignore it if you wish.
> 
> 
> 
> -- 
> 
> Terry Jan Reedy

Well, what I interpret as the PEP8 79 is chars visible minus the '\n' or '\r\n'(which would be 2; 81) line enders.
This is not stated in PEP8. PEP8 needs a bit of revision anyway, In my opinion... According to real-world standards for equipment/devices.
linking to a table/list of affected devices/minNumbers should be the norm.
or....

...

from codingguidelines import PEPStandards

... or something similar(Official PEP Zen Guidelines)

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

#53758

On Thu, 05 Sep 2013 19:59:34 -0700, Metallicow wrote:

> PEP8 needs a bit of revision anyway, In my opinion... According to
> real-world standards for equipment/devices. linking to a table/list of
> affected devices/minNumbers should be the norm. or....

I don't believe you have thought this through, or in any detail. The 
first problem is, what "real-world standards" are you talking about? What 
sort of devices are you referring to? How is this supposed to work in 
practice? If I write a Python module, which device am I supposed to pick?

It's a particularly ill-thought-out suggestion when you consider than PEP 
8 is for the Python standard library, and any document in the std lib 
will be read on a vast number of different devices, using different 
monitors with different screen resolutions and different widths, in 
different editors using different typefaces on different operating 
systems by people of different visual acuity.

The point of a coding standard for maximum line width is to average out 
all those myriad differences and give something which works pretty well 
overall regardless of the device. In other words, the coding standard 
defines a minimum capability (in this case, "you can display at least 79 
characters per line") and recommends you write to that standard.


> from codingguidelines import PEPStandards
> 
> ... or something similar(Official PEP Zen Guidelines)

And that's especially badly thought out. How is an import that occurs 
when the code is *run* supposed to make a difference to the way the code 
is *written*?


-- 
Steven

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

#53761

On Thursday, September 5, 2013 11:01:31 PM UTC-5, Steven D'Aprano wrote:
> And that's especially badly thought out. How is an import that occurs 
> when the code is *run* supposed to make a difference to the way the code 
> is *written*?

Proofreading.
Or maybe call it pre typesetting.

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

#53786

On Thursday, September 5, 2013 11:01:31 PM UTC-5, Steven D'Aprano wrote:
> On Thu, 05 Sep 2013 19:59:34 -0700, Metallicow wrote:
> > PEP8 needs a bit of revision anyway, In my opinion... According to
> > real-world standards for equipment/devices. linking to a table/list of
> > affected devices/minNumbers should be the norm. or....
> 
> I don't believe you have thought this through, or in any detail. The 
> first problem is, what "real-world standards" are you talking about? What 
> sort of devices are you referring to? How is this supposed to work in 
> practice? If I write a Python module, which device am I supposed to pick?

http://en.wikipedia.org/wiki/Revision
Why even define a number?
I causes people to argue about it. It is a variable.
I meant a "Reference" Table of equipment/devices.
Most Auto shop have a "Cross-Reference book". Also Johnny Cash built a vehicle from 30 years or so different years parts(or I know people who do/can).
Reference PEP8 standard to: A Technical manual per say.
If not make it simple. A multiple of 10, 80 being the closest int and also errors on 79 devices. Which then said device should be added to the reference manual. Or 70.
Also the pro/cons of this argument should be added to a "Quick-Reference".

Sorry if my opinion was not clear, the first time I posted. As I have been answered before, you CANNOT edit posts here. But you could with python... 

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

#53793

Google(will) Search This Message:
Industry Standards, PEP8, Whitespace, Print, Printing, Opinion'
I could add more... For example: Pantone color wheel.

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

#53773

> Well, what I interpret as the PEP8 79 is chars visible minus the '\n' or '\r\n'(which would be 2; 81) line enders.

You young un's. Always makin' stuff up... :-)

In these days of fancy single-user PCs with sophisticated window
systems, people tend to forget that BITD there was a thriving market
for serially-connected terminals (most only had 80 columns and 24
rows) connected to timesharing machines of various kinds (DEC VAX and
PDP-11 machines were extremely common in the Unix world). Many (some?
most? all?) of those terminals had a "feature" where if a character
was displayed in column 80, the cursor would automatically wrap around
and blink mindlessly in column 1 of the next row. That was even more
unpleasant behavior if you happened to enter text in the last column
of the last row, as then your cursor would blink in row 1, column 1. I
think there is a termcap code that specifies whether or not a given
terminal exhibits this behavior.

Hence 79.

/etc/termcap on my OpenSuSE system has over 1600 entries, most for
terminals which were resigned to the junk heap decades ago. Today, we
can probably just get by with entries for a couple xterm or ansi
variants.

And thank goodness for SIGWINCH. :-)

Skip

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

#53776

On 2013-09-06 05:09, Skip Montanaro wrote:
> And thank goodness for SIGWINCH. :-)

BEDEVERE: How do you know she is a SIGWINCH?

VILLAGER: She looks like one.

CROWD: Right! Yeah! Yeah!


:-)

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.

-tkc

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

#53777

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

On 6 September 2013 20:35, Tim Chase <python.list@tim.thechases.com> wrote:

> On 2013-09-06 05:09, Skip Montanaro wrote:
> > And thank goodness for SIGWINCH. :-)
>
> BEDEVERE: How do you know she is a SIGWINCH?
>
> VILLAGER: She looks like one.
>
> CROWD: Right! Yeah! Yeah!
>
>
> :-)
>
> 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.

Tim Delaney

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

#53782

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

Excuse me if this may be improper in you native language, butt...
If the interpreter didn't have a sense of humor, I believe most people wouldn't use python.

Most often it will return an answer, that is concise, but with a bit of flair.

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

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

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

csiph-web