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

#51490 — Re: PEP8 79 char max

On 07/29/2013 04:08 PM, Joel Goldstick wrote:
> On Mon, Jul 29, 2013 at 3:43 PM, Devyn Collier Johnson
> <devyncjohnson@gmail.com> wrote:
>> In Python programming, the PEP8 recommends limiting lines to a maximum of 79
>> characters because "There are still many devices around that are limited to
>> 80 character lines" (http://www.python.org/dev/peps/pep-0008/#code-lay-out).
>> What devices cannot handle 80 or more characters on a line?
> well, punch cards ;)
>   Would following
>> this recommendation improve script performance?
> Not performance, but human readability
>> Mahalo,
>>
>> Devyn Collier Johnson
>> DevynCJohnson@Gmail.com
>> --
>> http://mail.python.org/mailman/listinfo/python-list
>
>
So, I can have a script with large lines and not negatively influence 
performance on systems that do not use punch cards?

DCJ

[toc] | [next] | [standalone]

#51505

On Mon, 29 Jul 2013 16:24:51 -0400, Devyn Collier Johnson wrote:

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

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

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



-- 
Steven

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

#51512

On 07/29/2013 05:42 PM, Steven D'Aprano wrote:
> On Mon, 29 Jul 2013 16:24:51 -0400, Devyn Collier Johnson wrote:
>
>> So, I can have a script with large lines and not negatively influence
>> performance on systems that do not use punch cards?
> You'll negatively influence anyone who has to read, or edit, your code.
> Very likely including you.
>
> But no, there's no meaningful performance difference based on line
> length. Interpreting the source code is not meaningfully affected by line
> length, and by the time the code is compiled and then run, line length is
> irrelevant.
>
>
>
Evidently, it is personal preference. I prefer to read computer code 
like a book (yes, I am a weirdo (^u^)). The only time I exced 79 
characters is when I write a set of commands that perform similar tasks. 
I do not make too many lines over 79 char. Thanks everyone for the 
comments and feedback.

Mahalo,

DCJ

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

#51517

On Jul 29, 2013, at 5:30 PM, Devyn Collier Johnson <devyncjohnson@gmail.com> wrote:

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

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

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


-- Ed Leafe

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

#51584

Ed Leafe wrote:

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

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


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

-- 
ZeD

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

#51589

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

On 30 July 2013 18:08, Vito De Tullio <vito.detullio@gmail.com> wrote:

> Ed Leafe wrote:
>
> > I had read about a developer who switched to using proportional fonts for
> > coding, and somewhat skeptically, tried it out. After a day or so it
> > stopped looking strange, and after a week it seemed so much easier to
> > read.
>
> By my (limited) experience with proportional fonts, they can be useful only
> with something like elastic tabstops[0]. But, as a general rule, I simply
> found more "squared" to just use a fixed-width font.
>

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


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

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

#51590

On 2013-07-30, Joshua Landau <joshua@landau.ws> wrote:
> On 30 July 2013 18:08, Vito De Tullio <vito.detullio@gmail.com> wrote:
>
>> Ed Leafe wrote:
>>
>> > I had read about a developer who switched to using proportional fonts for
>> > coding, and somewhat skeptically, tried it out. After a day or so it
>> > stopped looking strange, and after a week it seemed so much easier to
>> > read.
>>
>> By my (limited) experience with proportional fonts, they can be useful only
>> with something like elastic tabstops[0]. But, as a general rule, I simply
>> found more "squared" to just use a fixed-width font.
>>
>
> Not if you give up on the whole "aligning" thing.

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

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

-- 
Grant Edwards               grant.b.edwards        Yow! MMM-MM!!  So THIS is
                                  at               BIO-NEBULATION!
                              gmail.com            

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

#51624

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

On 30 July 2013 18:52, Grant Edwards <invalid@invalid.invalid> wrote:

> On 2013-07-30, Joshua Landau <joshua@landau.ws> wrote:
> > On 30 July 2013 18:08, Vito De Tullio <vito.detullio@gmail.com> wrote:
> >
> >> Ed Leafe wrote:
> >>
> >> > I had read about a developer who switched to using proportional fonts
> for
> >> > coding, and somewhat skeptically, tried it out. After a day or so it
> >> > stopped looking strange, and after a week it seemed so much easier to
> >> > read.
> >>
> >> By my (limited) experience with proportional fonts, they can be useful
> only
> >> with something like elastic tabstops[0]. But, as a general rule, I
> simply
> >> found more "squared" to just use a fixed-width font.
> >>
> >
> > Not if you give up on the whole "aligning" thing.
>
> You don't think that Python code at a given level should all be
> aligned?  I find it very helpful when a given block of code is
> visually left-aligned.
>

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

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

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

open stuff stuff stuff close

to

open
    stuff
    stuff
    stuff
close

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

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

Why do you have tables in your Python code?

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

#51639

On 2013-07-31 07:16, Joshua Landau wrote:
> On 30 July 2013 18:52, Grant Edwards wrote:
>> I also find intializers for tables of data to be much more easily
>> read and maintained if the columns can be aligned.
> 
> Why do you have tables in your Python code?

I've had occasion to write things like:

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

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

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

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

-tkc

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

#51650

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?
>
> I've had occasion to write things like:
>
>   for name, value, description in (
>       ("cost", 42, "How much it cost"),
>       ("status", 3141, "Status code from ISO-3.14159"),
>       ...
>       ):
>     do_something(name, value)
>     print(description)
>
> I interpret Grant's statement as wanting the "table" to look like
>
>   for name, value, description in (
>       ("cost",   42,   "How much it cost"),
>       ("status", 3141, "Status code from ISO-3.14159"),
>       ...
>       ):
>     do_something(name, value)
>     print(description)
>
> which does give some modest readability benefits, but at a
> creation cost I personally am unwilling to pay.

I'm actually OK with the creation cost, but not the maintenance cost.

-- 
Neil Cerutti

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

#51669

On 2013-07-31, Neil Cerutti <neilc@norwich.edu> 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?
>>
>> I've had occasion to write things like:
>>
>>   for name, value, description in (
>>       ("cost", 42, "How much it cost"),
>>       ("status", 3141, "Status code from ISO-3.14159"),
>>       ...
>>       ):
>>     do_something(name, value)
>>     print(description)
>>
>> I interpret Grant's statement as wanting the "table" to look like
>>
>>   for name, value, description in (
>>       ("cost",   42,   "How much it cost"),
>>       ("status", 3141, "Status code from ISO-3.14159"),
>>       ...
>>       ):
>>     do_something(name, value)
>>     print(description)
>>
>> which does give some modest readability benefits, but at a
>> creation cost I personally am unwilling to pay.
>
> I'm actually OK with the creation cost, but not the maintenance cost.

In my experience, aligning columns in large tables reduces maintence
cost by making it much easier/faster to see what you've got and by
providing a way to visually "prompt" you for the correct value in the
correct place when you add new lines.

-- 
Grant Edwards               grant.b.edwards        Yow! hubub, hubub, HUBUB,
                                  at               hubub, hubub, hubub, HUBUB,
                              gmail.com            hubub, hubub, hubub.

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

#51676

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

>
> In my experience, aligning columns in large tables reduces maintence
> cost by making it much easier/faster to see what you've got and by
> providing a way to visually "prompt" you for the correct value in the
> correct place when you add new lines.
>
>
Works great until one of the values changes in size. Say:
bla = (
....1.0, 1.1, 1.2,
....2.0, 2.1, 2.2,
....3.0, 2.1, 3.2,
)

And one day you have to change '2.1' to '2.09999':
bla = (
....1.0, 1.1, 1.2,
....2.0, 2.09999, 2.2,
....3.0, 2.1, 3.2,
)

If this happens more than once ( or twice, because I'm patient =)),
maintaining the alignment becomes a chore. So I only align columns if I'm
typing a table I know won't change.


-- 
Marcelo Mallmann Dias

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

#51678

On 2013-07-31, Marcelo MD <lists.md@gmail.com> wrote:
>> In my experience, aligning columns in large tables reduces
>> maintence cost by making it much easier/faster to see what
>> you've got and by providing a way to visually "prompt" you for
>> the correct value in the correct place when you add new lines.
>
> Works great until one of the values changes in size. Say:
> bla = (
> ....1.0, 1.1, 1.2,
> ....2.0, 2.1, 2.2,
> ....3.0, 2.1, 3.2,
> )
>
> And one day you have to change '2.1' to '2.09999':
> bla = (
> ....1.0, 1.1, 1.2,
> ....2.0, 2.09999, 2.2,
> ....3.0, 2.1, 3.2,
> )
>
> If this happens more than once ( or twice, because I'm patient =)),
> maintaining the alignment becomes a chore. So I only align columns if I'm
> typing a table I know won't change.

Yes, that was my exprience, too.

Besides, after studying The Pragmatic Programmer I removed nearly
all the tables from my code and reference them (usually with csv
module) instead.

-- 
Neil Cerutti

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

#51681

On 2013-07-31, Neil Cerutti <neilc@norwich.edu> wrote:

> Besides, after studying The Pragmatic Programmer I removed nearly
> all the tables from my code and reference them (usually with csv
> module) instead.

I don't understand.  That just moves them to a different file --
doesn't it?  You've still got to deal with editing a large table of
data (for example when I want to add instructions to your assembler).

-- 
Grant Edwards               grant.b.edwards        Yow! Spreading peanut
                                  at               butter reminds me of
                              gmail.com            opera!!  I wonder why?

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

#51688

On 2013-07-31, Grant Edwards <invalid@invalid.invalid> wrote:
> On 2013-07-31, Neil Cerutti <neilc@norwich.edu> wrote:
>> Besides, after studying The Pragmatic Programmer I removed
>> nearly all the tables from my code and reference them (usually
>> with csv module) instead.
>
> I don't understand.  That just moves them to a different file
> -- doesn't it?  You've still got to deal with editing a large
> table of data (for example when I want to add instructions to
> your assembler).

Yes, but it is much easier to manipulate and view. I often still
edit the tables with Vim, but when I just want to view them I can
open them with Excel and get a very attractive display or
printout with minimal effort.

If it turns out I need to convert the table to some new format,
tools are abundant.

A couple of big wins:

It turned out later that some other entity needed the same data.

It has allowed me to add functionality to my program without even
editing the program.

Wouldn't be cool to add a new instruction by to my assembler,
including documentation, merely by editing a csv file? (I admit
that would need quite a bit of engineering to work, but it would
be cool.)

-- 
Neil Cerutti

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

#51691

On 2013-07-31, Neil Cerutti <neilc@norwich.edu> wrote:
> On 2013-07-31, Grant Edwards <invalid@invalid.invalid> wrote:
>> On 2013-07-31, Neil Cerutti <neilc@norwich.edu> wrote:
>>> Besides, after studying The Pragmatic Programmer I removed
>>> nearly all the tables from my code and reference them (usually
>>> with csv module) instead.
>>
>> I don't understand.  That just moves them to a different file
>> -- doesn't it?  You've still got to deal with editing a large
>> table of data (for example when I want to add instructions to
>> your assembler).
>
> Yes, but it is much easier to manipulate and view. I often still
> edit the tables with Vim, but when I just want to view them I can
> open them with Excel and get a very attractive display or
> printout with minimal effort.

If you're good at Excel.  I use a spreadsheet at most a few times a
year, and it has been many years since I've used Excel.  I find that
doing _anything_ with Excel generally involves at least an hour of
hairpulling and swearing.  Libreoffice isn't much better.

> If it turns out I need to convert the table to some new format,
> tools are abundant.

True.

> A couple of big wins:
>
> It turned out later that some other entity needed the same data.

It would save the two seconds it takes to extract the lines from the
Python file.

> It has allowed me to add functionality to my program without even
> editing the program.

Now you're playing with semantics.  If I have a bunch of lines
containing values separated by commas, and I'm editting them, then it
makes no difference to me which file they're in -- I'm still adding
functionality be editing a table of data.

> Wouldn't be cool to add a new instruction by to my assembler,
> including documentation, merely by editing a csv file? (I admit
> that would need quite a bit of engineering to work, but it would
> be cool.)

Yes, that's cool, and that's pretty much how it works.  Those csv
lines just happen to be in the same file as the rest of the assembler
source rather than in a second file.

-- 
Grant Edwards               grant.b.edwards        Yow! Hello?  Enema Bondage?
                                  at               I'm calling because I want
                              gmail.com            to be happy, I guess ...

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

#51697

On 2013-07-31, Grant Edwards <invalid@invalid.invalid> wrote:
> On 2013-07-31, Neil Cerutti <neilc@norwich.edu> wrote:
>> On 2013-07-31, Grant Edwards <invalid@invalid.invalid> wrote:
>>> On 2013-07-31, Neil Cerutti <neilc@norwich.edu> wrote:
>>>> Besides, after studying The Pragmatic Programmer I removed
>>>> nearly all the tables from my code and reference them (usually
>>>> with csv module) instead.
>>>
>>> I don't understand.  That just moves them to a different file
>>> -- doesn't it?  You've still got to deal with editing a large
>>> table of data (for example when I want to add instructions to
>>> your assembler).
>>
>> Yes, but it is much easier to manipulate and view. I often still
>> edit the tables with Vim, but when I just want to view them I can
>> open them with Excel and get a very attractive display or
>> printout with minimal effort.
>
> If you're good at Excel.  I use a spreadsheet at most a few times a
> year, and it has been many years since I've used Excel.  I find that
> doing _anything_ with Excel generally involves at least an hour of
> hairpulling and swearing.  Libreoffice isn't much better.
>
>> If it turns out I need to convert the table to some new format,
>> tools are abundant.
>
> True.
>
>> A couple of big wins:
>>
>> It turned out later that some other entity needed the same
>> data.
>
> It would save the two seconds it takes to extract the lines
> from the Python file.

...assuming I'm not creating a maintenance problem by duplicating
the table. Most likely you would end up externalizing the table
at that point, right?

>> It has allowed me to add functionality to my program without
>> even editing the program.
>
> Now you're playing with semantics.  If I have a bunch of lines
> containing values separated by commas, and I'm editting them,
> then it makes no difference to me which file they're in -- I'm
> still adding functionality be editing a table of data.

The separation of data and program is more distinct in my
version, but you're right, of course. An internal representation
in addition has the advantage of being able to directly use
Python identifiers and expressions, too. But if you take
advantage of those features when the time comes to externalize
your data it's more work.

The only cost you pay more than what I've already spent at that
point is whatever time you spent creating the non-external
version to begin with.

-- 
Neil Cerutti

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

#51690

Grant Edwards wrote:
> On 2013-07-31, Neil Cerutti <neilc@norwich.edu> wrote:
> 
> > Besides, after studying The Pragmatic Programmer I removed nearly
> > all the tables from my code and reference them (usually with csv
> > module) instead.
> 
> I don't understand.  That just moves them to a different file --
> doesn't it?  You've still got to deal with editing a large table of
> data (for example when I want to add instructions to your assembler).
> 
> --
> Grant Edwards               grant.b.edwards        Yow! Spreading peanut
>                                   at               butter reminds me of
>                               gmail.com            opera!!  I wonder why?
> --

True, but a CSV file is easy to edit in something like a spreadsheet
application (LibreOffice/MS Office); alignment becomes automatic
then.


Ramit





This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email.  

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

#51680

=> Works great until one of the values changes in size.

Slightly off-topic, but still sort of related (talking about the size
of things), I started picking 1e+30 as my "really big" some time back
because the repr of 1e+99 required more than a glance when it appeared
in printed output:

>>> repr(1e+30)
'1e+30'
>>> repr(1e+99)
'9.9999999999999997e+98'

This problem was fixed in 2.7 (and presumably in 3.something as well),
but it used to be a problem. :-)

Skip

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

#51668

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.

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

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

-- 
Grant Edwards               grant.b.edwards        Yow! I am NOT a nut....
                                  at               
                              gmail.com            

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web