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

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

PEP 8 : Maximum line Length :

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

Contents

  PEP 8 : Maximum line Length : Ganesh Pal <ganesh1pal@gmail.com> - 2014-05-13 12:37 +0530
    Re: PEP 8 : Maximum line Length : Rustom Mody <rustompmody@gmail.com> - 2014-05-13 04:52 -0700
      Re: PEP 8 : Maximum line Length : Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-13 13:46 +0000
        Re: PEP 8 : Maximum line Length : Ben Finney <ben@benfinney.id.au> - 2014-05-14 08:55 +1000
          Re: PEP 8 : Maximum line Length : Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-05-14 12:24 +1200
        Re: PEP 8 : Maximum line Length : Terry Reedy <tjreedy@udel.edu> - 2014-05-14 17:09 -0400
      Re: PEP 8 : Maximum line Length : albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-05-14 22:53 +0000
        Re: PEP 8 : Maximum line Length : Gary Herron <gary.herron@islandtraining.com> - 2014-05-14 17:15 -0700
        Re: PEP 8 : Maximum line Length : Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-05-15 02:16 +0100
          Re: PEP 8 : Maximum line Length : Roy Smith <roy@panix.com> - 2014-05-14 22:12 -0400
            Re: PEP 8 : Maximum line Length : Dave Angel <davea@davea.name> - 2014-05-15 08:16 -0400
        Re: PEP 8 : Maximum line Length : Rustom Mody <rustompmody@gmail.com> - 2014-05-14 19:36 -0700
          Re: PEP 8 : Maximum line Length : Ben Finney <ben@benfinney.id.au> - 2014-05-15 12:43 +1000
            Re: PEP 8 : Maximum line Length : Johannes Bauer <dfnsonfsduifb@gmx.de> - 2014-05-15 14:32 +0200
              Re: PEP 8 : Maximum line Length : Marko Rauhamaa <marko@pacujo.net> - 2014-05-15 16:07 +0300
                Re: PEP 8 : Maximum line Length : Chris Angelico <rosuav@gmail.com> - 2014-05-15 23:31 +1000
                  Re: PEP 8 : Maximum line Length : alister <alister.nospam.ware@ntlworld.com> - 2014-05-15 13:38 +0000
                    Re: PEP 8 : Maximum line Length : Chris Angelico <rosuav@gmail.com> - 2014-05-15 23:44 +1000
                      Re: PEP 8 : Maximum line Length : alister <alister.nospam.ware@ntlworld.com> - 2014-05-15 19:29 +0000
                Re: PEP 8 : Maximum line Length : Rustom Mody <rustompmody@gmail.com> - 2014-05-15 06:53 -0700
                  Re: PEP 8 : Maximum line Length : Roy Smith <roy@panix.com> - 2014-05-15 09:58 -0400
                    Re: PEP 8 : Maximum line Length : Chris Angelico <rosuav@gmail.com> - 2014-05-16 00:14 +1000
                    Re: PEP 8 : Maximum line Length : Rustom Mody <rustompmody@gmail.com> - 2014-05-15 07:15 -0700
                      Re: PEP 8 : Maximum line Length : Marko Rauhamaa <marko@pacujo.net> - 2014-05-15 17:29 +0300
                        Re: PEP 8 : Maximum line Length : Skip Montanaro <skip@pobox.com> - 2014-05-15 09:38 -0500
                        Re: PEP 8 : Maximum line Length : Chris Angelico <rosuav@gmail.com> - 2014-05-16 00:42 +1000
                        Re: PEP 8 : Maximum line Length : Terry Reedy <tjreedy@udel.edu> - 2014-05-15 17:50 -0400
                        Re: PEP 8 : Maximum line Length : MRAB <python@mrabarnett.plus.com> - 2014-05-16 01:05 +0100
                    Re: PEP 8 : Maximum line Length : Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-05-15 17:18 +0100
                  Re: PEP 8 : Maximum line Length : Marko Rauhamaa <marko@pacujo.net> - 2014-05-15 17:12 +0300
                    Re: PEP 8 : Maximum line Length : Chris Angelico <rosuav@gmail.com> - 2014-05-16 00:24 +1000
                      Re: PEP 8 : Maximum line Length : Marko Rauhamaa <marko@pacujo.net> - 2014-05-15 17:36 +0300
                        Re: PEP 8 : Maximum line Length : Chris Angelico <rosuav@gmail.com> - 2014-05-16 01:03 +1000
                    Re: PEP 8 : Maximum line Length : Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-16 06:25 +0000
                      Re: PEP 8 : Maximum line Length : Ben Finney <ben@benfinney.id.au> - 2014-05-16 16:54 +1000
                      Re: PEP 8 : Maximum line Length : Marko Rauhamaa <marko@pacujo.net> - 2014-05-16 10:00 +0300
                        Re: PEP 8 : Maximum line Length : Chris Angelico <rosuav@gmail.com> - 2014-05-16 17:39 +1000
                          Re: PEP 8 : Maximum line Length : Marko Rauhamaa <marko@pacujo.net> - 2014-05-16 12:18 +0300
                            Re: PEP 8 : Maximum line Length : Chris Angelico <rosuav@gmail.com> - 2014-05-16 19:40 +1000
                              Re: PEP 8 : Maximum line Length : Marko Rauhamaa <marko@pacujo.net> - 2014-05-16 13:48 +0300
                      Re: PEP 8 : Maximum line Length : Chris Angelico <rosuav@gmail.com> - 2014-05-16 17:36 +1000
                Re: PEP 8 : Maximum line Length : Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-16 00:21 +0000
              Re: PEP 8 : Maximum line Length : Chris Angelico <rosuav@gmail.com> - 2014-05-15 23:27 +1000
                Re: PEP 8 : Maximum line Length : Rustom Mody <rustompmody@gmail.com> - 2014-05-15 06:58 -0700
                  Re: PEP 8 : Maximum line Length : Terry Reedy <tjreedy@udel.edu> - 2014-05-15 18:21 -0400
                    Re: PEP 8 : Maximum line Length : Rustom Mody <rustompmody@gmail.com> - 2014-05-15 17:06 -0700
                      Re: PEP 8 : Maximum line Length : Ben Finney <ben@benfinney.id.au> - 2014-05-16 10:21 +1000
                        Re: PEP 8 : Maximum line Length : Rustom Mody <rustompmody@gmail.com> - 2014-05-15 20:03 -0700
                          Re: PEP 8 : Maximum line Length : Ben Finney <ben@benfinney.id.au> - 2014-05-16 16:12 +1000
                      Re: PEP 8 : Maximum line Length : Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-16 07:05 +0000
                  Re: PEP 8 : Maximum line Length : Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-16 02:25 +0000
              Re: PEP 8 : Maximum line Length : Ben Finney <ben@benfinney.id.au> - 2014-05-16 09:32 +1000
          Re: PEP 8 : Maximum line Length : Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-15 03:28 +0000
            Re: PEP 8 : Maximum line Length : Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-05-15 20:18 -0400
          Re: PEP 8 : Maximum line Length : Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-05-15 04:44 +0100
    Re: PEP 8 : Maximum line Length : Roy Smith <roy@panix.com> - 2014-05-13 08:09 -0400
      Re: PEP 8 : Maximum line Length : Ben Finney <ben@benfinney.id.au> - 2014-05-13 22:26 +1000
        Re: PEP 8 : Maximum line Length : Roy Smith <roy@panix.com> - 2014-05-13 20:51 -0400
      Re: PEP 8 : Maximum line Length : Tim Chase <python.list@tim.thechases.com> - 2014-05-13 07:52 -0500

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

#71605

In article <78ac407a-c429-4a7a-93c9-5d83e0f09cbb@googlegroups.com>,
 Rustom Mody <rustompmody@gmail.com> wrote:

> And yet programmers continue to be decades behind all other users of 
> computers.  We continue to use flat text for our programs when all others 
> have moved on.

It's not like we haven't tried.  There have been a few attempts at using 
richer media to program (graphical UML editors, for example).  They've 
all pretty much been failures.

There *are* some places where non-text programming has won.  The biggest 
example would be GUI builders.  Nobody programs screen and window 
layouts by typing textual descriptions.  They push boxes around in a GUI 
builder.

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

#71608

On Thu, May 15, 2014 at 11:58 PM, Roy Smith <roy@panix.com> wrote:
> There *are* some places where non-text programming has won.  The biggest
> example would be GUI builders.  Nobody programs screen and window
> layouts by typing textual descriptions.  They push boxes around in a GUI
> builder.

Hi, I'm Nobody, and I like warm hugs!

My GUI building is entirely by typing textual descriptions. Yes, there
are some good builders, but I do my layouts on a basis of rules rather
than strict pixel positions. Rules and bag-based layouts mean there's
no problem with something getting too big and messing up your layout.

Is it really helpful to drag objects into a nearly-invisible "Vertical
Box" container? Pushing boxes around is great when you attach
everything directly to the window, but that gets messed up pretty
quickly by a user's themes, font sizes, etc (not to mention a change
of platform). Explicitly putting things into their boxes, grids,
tables, etc means it's always right.

ChrisA

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

#71609

On Thursday, May 15, 2014 7:28:01 PM UTC+5:30, Roy Smith wrote:
> 
>  Rustom Mody wrote:
> 
> 
> 
> > And yet programmers continue to be decades behind all other users of 
> > computers.  We continue to use flat text for our programs when all others 
> > have moved on.
> 
> 
> 
> It's not like we haven't tried.  There have been a few attempts at using 
> richer media to program (graphical UML editors, for example).  They've 
> all pretty much been failures.
> 

In Fifth Discipline, Peter Senge starts by dilating on the length of time between
1903 when the Wright brothers first flew and 1935 when the DC-3 ushered in commercial air travel.

Five things were needed for that transition from pioneering to commercial:

| They were: the variable-pitch propeller, retractable landing gear, a type of 
| lightweight molded body construction called "monocque," radial air-cooled 
| engine, and wing flaps. To succeed, the DC-3 needed all five; four were not 
| enough. One year earlier, the Boeing 247 was introduced with all of them except 
| wing flaps. Lacking wing flaps, Boeing's engineers found that the plane was 
| unstable on take-off and landing and had to downsize the engine.

So maybe you are just being pessimistic when in fact we are in the (equivalent of)
that 30 year period?

Two more examples:
Dijkstra pointed out that it typically takes an idea a hundred years from discovery 
to mainstream. Think Cantor inventing set theory in 1880s, modern math entering
schools in 1970s.

A more extreme example: Europeans learnt first of Hindu-Arabic numerals in around
1000 AD. IT took a good 500 years to give up on Roman numerals

> 
> 
> There *are* some places where non-text programming has won.  The biggest 
> example would be GUI builders.  Nobody programs screen and window 
> layouts by typing textual descriptions.  They push boxes around in a GUI 
> builder.

And yet you routinely find people on this list recommending writing python to using
a GUI-builder.
On the one hand I am tempted to say "Sheesh!!"
On the other, maybe the builders are still too half-assed... Dunno

[BTW is there any equivalent for html?]

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

#71613

Rustom Mody <rustompmody@gmail.com>:

> And yet you routinely find people on this list recommending writing
> python to using a GUI-builder. On the one hand I am tempted to say
> "Sheesh!!" On the other, maybe the builders are still too
> half-assed... Dunno

That's like diagnosing cancer without invasive procedures, lab tests and
interviews: the doctor should be able to look at how pale you look and
if your skin has any funny bulges.

Thing is, programs and even text documents and spreadsheets have a lot
more abstract structure, dynamics and dependencies than the visible
façade. Block diagrams and graphics can be great presentation tools, but
nothing beats text in concise, explicit expressiveness.

An everyday example: a word processor displays the word "hello" with
"hel" in boldface and "lo" in italics. You put the cursor between the
l's and type a letter. Should it be in boldface or italics?

Who of you hasn't sworn at a Web editor that gets the formatting all
messed up when you have typed a backspace in the "wrong place?"


Marko

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

#71615

On Thu, May 15, 2014 at 9:29 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Who of you hasn't sworn at a Web editor that gets the formatting all
> messed up when you have typed a backspace in the "wrong place?"

My current pet peeve is the Gmail composition pane. What a load of
crap (especially in rich text mode).

You set the font to Sans Serif, start typing. Everything is in
Courier. Select All, switch everything to Sans Serif, and it redraw
the text, still in Courier, but in a different version of Courier.
Switch back to plain text mode. It has not-too-helpfully inserted line
breaks everywhere the rich text editor surrounded text with <div>
tags. Go back and delete all of them. Edit your text. Proofread your
text. Switch back to rich text so you can insert the image you wanted
to display. Hit Send.

Haven't we had WYSIWYG editors for about 40 years?

Skip

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

#71616

On Fri, May 16, 2014 at 12:29 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
> An everyday example: a word processor displays the word "hello" with
> "hel" in boldface and "lo" in italics. You put the cursor between the
> l's and type a letter. Should it be in boldface or italics?

Impossible to say, and one of the perpetual annoyances. Here's a web
site that I host:

http://gilbertandsullivan.org.au/index.php?option=com_content&view=article&id=92:2001-patience&catid=30:patience&Itemid=102

(Tiny URL: http://tinyurl.com/pphpkuk )

Why is "Lt Duke of Dunstable" different from all the other character
names? (By the way, I just picked an article at random from the
archive, and the first random pick had an example of what I'm talking
about. It's fairly prevalent on that site.) Now, if this were
hand-written HTML2, this sort of thing wouldn't happen; and, even
better, if the structure and formatting were properly separated (as in
my proposed web site redesign), they'd not only be guaranteed
consistent within a page, but also *across* pages.

Tagged text works well. In HTML pages, that means literal
<angle><bracket><tags>; in programming, that's all our various
notations and things. I wouldn't want to write code by writing a bunch
of words and then marking "This word is an assignment target, this one
is an object that you should find a method on, this one is the method
name, and these ones are the arguments". I want to put = . ( ) to mark
those. More efficient... MUCH more reliable. And, bonus: it's all
text.

ChrisA

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

#71626

On 5/15/2014 10:42 AM, Chris Angelico wrote:

> Impossible to say, and one of the perpetual annoyances. Here's a web
> site that I host:
>
> http://gilbertandsullivan.org.au/index.php?option=com_content&view=article&id=92:2001-patience&catid=30:patience&Itemid=102
>
> (Tiny URL: http://tinyurl.com/pphpkuk )
>
> Why is "Lt Duke of Dunstable" different from all the other character
> names?

For me, Windows FF, it is not different that I can see.


-- 
Terry Jan Reedy

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

#71630

On 2014-05-15 22:50, Terry Reedy wrote:
> On 5/15/2014 10:42 AM, Chris Angelico wrote:
>
>> Impossible to say, and one of the perpetual annoyances. Here's a web
>> site that I host:
>>
>> http://gilbertandsullivan.org.au/index.php?option=com_content&view=article&id=92:2001-patience&catid=30:patience&Itemid=102
>>
>> (Tiny URL: http://tinyurl.com/pphpkuk )
>>
>> Why is "Lt Duke of Dunstable" different from all the other character
>> names?
>
> For me, Windows FF, it is not different that I can see.
>
For me, with Firefox on Windows, it's slightly bolder, but that's
probably because its colour is specified, unlike the others.

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

#71620

On 15/05/2014 14:58, Roy Smith wrote:
> In article <78ac407a-c429-4a7a-93c9-5d83e0f09cbb@googlegroups.com>,
>   Rustom Mody <rustompmody@gmail.com> wrote:
>
>> And yet programmers continue to be decades behind all other users of
>> computers.  We continue to use flat text for our programs when all others
>> have moved on.
>
> It's not like we haven't tried.  There have been a few attempts at using
> richer media to program (graphical UML editors, for example).  They've
> all pretty much been failures.
>

This http://sourceforge.net/projects/doublesvsoop/ was project of the 
month just a little while ago, so it's obviously overcome all of the 
known obstacles, in exactly the same way that all previous silver 
bullets have done.  At least I think it's the kind of thing that you're 
talking about.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

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

#71607

Rustom Mody <rustompmody@gmail.com>:

> We continue to use flat text for our programs when all others have
> moved on.

My more moderate and immediate point is, why should the physical
encoding of the program be also the presentation format?

A definitive Python source file could be binary, XML, .py, .ast,
whatever, and that would also be the file fed to the Python
compiler/interpreter. However, your editor could choose freely how to
present it to you.

IOW, shouldn't PEP8 be redundant?


Marko

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

#71611

On Fri, May 16, 2014 at 12:12 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
> A definitive Python source file could be binary, XML, .py, .ast,
> whatever, and that would also be the file fed to the Python
> compiler/interpreter. However, your editor could choose freely how to
> present it to you.
>
> IOW, shouldn't PEP8 be redundant?

I believe the Python interpreter happily accepts a zip file, which in
theory could be edited directly by a competent text editor. But that
has nothing to do with PEP 8. Compare a classic compiled language like
C - you have the bit you edit (the C source code) and the "definitive
version" that's fed to the program loader (the compiled binary). Style
guides apply to the edited version, not to the executed version.

ChrisA

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

#71614

Chris Angelico <rosuav@gmail.com>:

> I believe the Python interpreter happily accepts a zip file, which in
> theory could be edited directly by a competent text editor. But that
> has nothing to do with PEP 8. Compare a classic compiled language like
> C - you have the bit you edit (the C source code) and the "definitive
> version" that's fed to the program loader (the compiled binary). Style
> guides apply to the edited version, not to the executed version.

My point applies to C as well. Shouldn't the .c file contain an AST?
Only when you open the file in your text editor, it makes it look like
you wrote it yourself in your favorite style?

You and I could have opened the same C file. Only you see:

   #include <stdio.h>

   int                                       +--------------------+
   main ( int     argc,                      | My first C program |
          char *const argv[] )               +--------------------+
   {
           (void) printf( "Hello world\n" );

           return(0);
   }

while I see:

   #include <stdio.h>

   /* My first C program */
   int main(int argc, char *const argv[]) {
     printf("Hello world\n");
     return 0;
   }


Marko

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

#71618

On Fri, May 16, 2014 at 12:36 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
> You and I could have opened the same C file. Only you see:
>
>    #include <stdio.h>
>
>    int                                       +--------------------+
>    main ( int     argc,                      | My first C program |
>           char *const argv[] )               +--------------------+
>    {
>            (void) printf( "Hello world\n" );
>
>            return(0);
>    }
>
> while I see:
>
>    #include <stdio.h>
>
>    /* My first C program */
>    int main(int argc, char *const argv[]) {
>      printf("Hello world\n");
>      return 0;
>    }

Well no, for two reasons. Firstly, I think the first one looks
disgusting, so even if I had that feature, I wouldn't use it like that
:)

But more importantly: You can already do that sort of thing, and it's
a bad idea. Maybe there aren't any text editors that can do it, but
you can use source control that way. (I'm going to use git as my
example, as I don't know how it's done in hg or any other; but I'm
sure it won't be hard.) You just tell git that these files (probably
"files matching glob *.c") are to be reformatted, and provide two
commands: one that cleans a file prior to it going into source
control, and one that "smudges" it at the other end. So you could
simply write a code reformatter and register it as your smudge
command, and (in the interests of readable diffs) have some
standardized reformatter as the clean command. Voila! You now can
check out my code with your formatting.

Which brings me to the second reason for not doing this. That
clean/smudge operation *destroys information*. Once you enforce code
formatting like that, you violate PEP 8's "rule zero": sometimes, it's
better to break the rules. Sometimes, your nice code reformatting
operation will actually make the program worse... and there'll be no
way for you to get back from that.

Not to mention that any reformatting that inserts or deletes lines is
a pain for debugging. "Line 42" on your screen and "Line 42" in the
traceback won't be the same thing any more. If I run your code and
give you an exception trace, you'll have to check out my version of
the code to be able to understand anything. Theoretically that could
be solved (eg you absolutely always run the checked-in version - of
course, that assumes that everyone's smudge and clean will perfectly
recreate the exact same output), but even with editor support, where
you'd move the cursor around and the line number would go berserk
(press down-arrow three times and the line number goes 5, 6, 6, 10),
it would be a pain.

Code is a text file. So is music (I use GNU LilyPond, and everything
works like code). So is data, in many many cases. So is configuration,
often, although some programs prefer to work with an opaque format.
About the only thing that really definitely shouldn't be massaged into
text is actual 2D images. Can you turn this into a few lines of code?

https://lh3.googleusercontent.com/-_8upQkJcvjE/UhTJlDzW3ZI/AAAAAAAABU8/QvExuUq47dI/s512/DSCF7600.JPG

Pretty much everything else, though, works better as plain text.

ChrisA

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

#71642

On Thu, 15 May 2014 17:12:57 +0300, Marko Rauhamaa wrote:

> A definitive Python source file could be binary, XML, .py, .ast,
> whatever, 

Containing *what*? You can't just wave your hands and say "binary". What 
sort of binary file? Perhaps a JPEG file, where red triangles of 
different sizes represent keywords. Variable names can be encoded using a 
pattern of purple dots. Expressions and blocks of code can be formed by 
joining components with lines. Operators by squares of different colours 
(green means +, blue means -, etc.).

No? Then what?

Besides, where does the information inside the file come from? You surely 
don't expect people to write the binary data/AST/whatever directly. How 
can the zip file be "definitive" when it is derived from something more 
fundamental?

Source code is, *by definition*, the definitive version. (It's the 
SOURCE, see?) Zipping the source code just means that the *source* inside 
the zip file is the definitive version, not the compressed binary data.

The AST is not definitive. Human beings write *text*, which is what the 
source code is. It may be text with an especially restrictive grammar, 
but it's still text. Everything else -- the parse tree, the abstract 
syntax tree, the byte code, the machine code, the compressed text, 
encrypted text, the pixel rendering of the text, ... are derived from the 
code as written by human beings.

Code is written primarily for human beings. Many programmers, and many 
language designers, don't realise this, which is why so many programs are 
write-only code. Presentation *is important*, and cannot always be 
separated from semantics without hurting the primary audience, the human 
reader. This is what code obfuscators do, deliberately: mangle the 
presentation while keeping the semantics the same. You're inadvertently 
proposing the same thing (albeit to a lesser degree).



-- 
Steven D'Aprano
http://import-that.dreamwidth.org/

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

#71644

Steven D'Aprano <steve+comp.lang.python@pearwood.info> writes:

> Source code is, *by definition*, the definitive version. (It's the
> SOURCE, see?) Zipping the source code just means that the *source*
> inside the zip file is the definitive version, not the compressed
> binary data.

I find the Free Software Foundation has a good, clear definition of
“source” for programs:

    The "source code" for a work means the preferred form of the work
    for making modifications to it.

(GNU General Public License, version 3 §1).

There is ambiguity there, but it's exactly where it needs to be:
focussing the discussion on what form of the work is preferred for
making modofications to it.

A byte stream is only source *with respect to some work*, and is only
the source of *that* work if it is the preferred form of that work for
making modifications to that work.

This neatly cuts of at the knees a whole mob of futile speculative
distractions about “who is to say whether one person might consider this
byte stream to be source”.

To hell with all that. We're interested in making modifications to a
work, and we reach for some form of the work to do so: *that* form is
the source for the work.

> The AST is not definitive. Human beings write *text*, which is what
> the source code is.

And if it's not text in some outlying cases, then it will only be
because some *other* form of the work which is preferred by actual human
programmers for making modifications to the work.

> Code is written primarily for human beings. Many programmers, and many
> language designers, don't realise this, which is why so many programs
> are write-only code. Presentation *is important*, and cannot always be
> separated from semantics without hurting the primary audience, the
> human reader. This is what code obfuscators do, deliberately: mangle
> the presentation while keeping the semantics the same. You're
> inadvertently proposing the same thing (albeit to a lesser degree).

Yes. And this is why obfuscated code, though it may be interpreted
without difficulty by the same compiler algorithm, still does not
constitute the source for the program.

-- 
 \      “Any intelligent fool can make things bigger and more complex… |
  `\    It takes a touch of genius – and a lot of courage – to move in |
_o__)                        the opposite direction.” —Albert Einstein |
Ben Finney

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

#71645

Steven D'Aprano <steve+comp.lang.python@pearwood.info>:

> On Thu, 15 May 2014 17:12:57 +0300, Marko Rauhamaa wrote:
>
>> A definitive Python source file could be binary, XML, .py, .ast,
>> whatever, 
>
> Containing *what*? You can't just wave your hands and say "binary".

I sure can and am.

> Besides, where does the information inside the file come from?

The file would a canonical serialization of the AST. The information
would come from an editor (say, emacs) that displays the AST as
two-dimensional text according to your preferences.

Analogy: How do you edit a .png file? With an editor (say, gimp).
Programming languages could work the same way.

> Source code is, *by definition*, the definitive version.

The AST file would be the source code, only it wouldn't have line
numbers or columns. Maybe it could even leave out
capitalization/camel-casing so the editor can display the variable,
function and class names according to your preferences.

> The AST is not definitive. Human beings write *text*, which is what the 
> source code is.

You are stuck to the status quo. I'm proposing the AST should be the
definitive source and the human beings would express AST through the
editor. Yes, it would probably be text, at least partly, but for example
the AST wouldn't specify the order of the function or class definitions.

> This is what code obfuscators do, deliberately: mangle the
> presentation while keeping the semantics the same. You're
> inadvertently proposing the same thing (albeit to a lesser degree).

At least, we could stop debating silly surface presentation issues
(indentation, line width, spacing around operators...).

Well, actually, any .py file *does* specify a unique AST. Nothing would
prevent the text editor from presenting it according to your
preferences. They all do that to a degree anyway (colors, fonts), but
they could take even more liberties (which some IDE's do: hiding/showing
comments and function definitions).

There are tools that reindent and refactor code automatically. The text
editor could do that on the fly.


Marko

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

#71648

On Fri, May 16, 2014 at 5:00 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Well, actually, any .py file *does* specify a unique AST. Nothing would
> prevent the text editor from presenting it according to your
> preferences. They all do that to a degree anyway (colors, fonts), but
> they could take even more liberties (which some IDE's do: hiding/showing
> comments and function definitions).
>
> There are tools that reindent and refactor code automatically. The text
> editor could do that on the fly.

You still haven't answered my biggest objection from earlier. Source
code contains more information than the AST does; even if you make a
frAnkenSTein's monster that includes comments, there's still the point
that whitespace carries information, and that information is
frequently communicative of the programmer's intent. Any automated
reformatter destroys that information, and that is, by definition, a
net loss to the code. How do you propose to fix that? Or if not, will
you at least acknowledge that the AST cannot perfectly transmit what
the source code says?

ChrisA

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

#71651

Chris Angelico <rosuav@gmail.com>:

> You still haven't answered my biggest objection from earlier. Source
> code contains more information than the AST does; even if you make a
> frAnkenSTein's monster that includes comments, there's still the point
> that whitespace carries information, and that information is
> frequently communicative of the programmer's intent. Any automated
> reformatter destroys that information, and that is, by definition, a
> net loss to the code. How do you propose to fix that? Or if not, will
> you at least acknowledge that the AST cannot perfectly transmit what
> the source code says?

If every bit of your Python text conveys information, obviously, it
can't be abstracted. I don't believe that to be the case, though. So
this AST should contain all *actual* information worth conveying and
strip away irrelevant stuff.

Examples:

 * Function definition order.

 * Indentation depth.

 * Vertical empty space.


Of course, I'm not being completely serious about all this stuff because
the surface coding style questions are among the least relevant problems
in the code. But at least that kind of arrangement would free us from
the heated debates concerning the maximum line length etc.

(BTW, regardless of PEP8, the maximum line length *must* be 79, and the
maximum function length *must* be whatever can be seen on the screen at
once.)


Marko

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

#71653

On Fri, May 16, 2014 at 7:18 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
> If every bit of your Python text conveys information, obviously, it
> can't be abstracted. I don't believe that to be the case, though. So
> this AST should contain all *actual* information worth conveying and
> strip away irrelevant stuff.
>
> Examples:
>
>  * Function definition order.
>
>  * Indentation depth.
>
>  * Vertical empty space.

* Logical layout as expressed by whitespace and specific line breaks.

Compare these two assignment statements:

area = (base*base + extension*extension
    + annex*annex + (annex-extension)*annex
    + triangle*triangle/2
    + circle*circle*math.PI + sphere*sphere*4*math.PI)

area = (base*base + extension*extension + annex*annex
    + (annex-extension)*annex + triangle*triangle/2
    + circle*circle*math.PI + sphere*sphere*4*math.PI)

Both are wrapped to sixty characters, which means they can be indented
twenty without breaking PEP 8. One of them takes up only three lines,
the other takes up four. But the first one groups the annex's terms,
separates out the triangle, groups the circular elements, and
presumably corresponds accurately to the (mythical) real-world
geometry that it's implementing. How are you going to cope with this
distinction? That's real, useful information, which the AST doesn't
carry.

(You might argue that each of these lines should have a comment at the
end of it or above it, which would provide that grouping. But in that
case, you lose the canonicalization of anything with trailing comments
or interspersed comments, meaning that you effectively can't reformat
anything with comments in it.)

ChrisA

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

#71655

Chris Angelico <rosuav@gmail.com>:

> Compare these two assignment statements:
>
> area = (base*base + extension*extension
>     + annex*annex + (annex-extension)*annex
>     + triangle*triangle/2
>     + circle*circle*math.PI + sphere*sphere*4*math.PI)
>
> area = (base*base + extension*extension + annex*annex
>     + (annex-extension)*annex + triangle*triangle/2
>     + circle*circle*math.PI + sphere*sphere*4*math.PI)
>
> [...]
> How are you going to cope with this distinction? That's real, useful
> information, which the AST doesn't carry.

Such nuances would be lost, yes. However, the nuances are constantly
abused and misinterpreted anyway.


Marko

[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