Striving for PEP-8 compliance

[Steven D'Aprano]

On Sat, 10 Apr 2010 10:31:58 +1200, Lawrence D'Oliveiro wrote:

> In message <4bbf6eb8$0$1670$742ec2ed at news.sonic.net>, John Nagle wrote:
> 
>> Lawrence D'Oliveiro wrote:
>>
>>> In message <mailman.1610.1270655932.23598.python-list at python.org>,
>>> Gabriel Genellina wrote:
>>> 
>>>> If you only reindent the code (without adding/removing lines) then
>>>> you can compare the compiled .pyc files (excluding the first 8 bytes
>>>> that contain a magic number and the source file timestamp). Remember
>>>> that code objects contain line number information.
>>> 
>>> Anybody who ever creates another indentation-controlled language
>>> should be beaten to death with a Guido van Rossum voodoo doll.
>> 
>>     No ...
> 
> Yes, because otherwise you wouldn’t have stupid problems like the one
> which is preoccupying this thread: how to make sure indentation is
> consistent without introducing logic errors into the code.


I don't see the problem here.

The OP has code which is already correctly indented. He wants to re-
indent it, from two spaces to four. As I see it, even a simple-minded 
string replacement from 2 to 4 spaces should Just Work, provided you 
don't care about extra spacing potentially being introduced into strings, 
comments, etc.

E.g. if you have this (already ugly) code:


def f(a):
  x =  42
  if a < 0:
    return a  # Return a untouched.
  else:
    for i   in range(  x  )  :  # Do pointless work
      pass
    this_is_a_very_long_line  = (   2, 4,  5, 
       7, 9    )
    return   a+1


and just do a simple string replacement, you get this:

def f(a):
    x =    42
    if a < 0:
        return a    # Return a untouched.
    else:
        for i     in range(    x    )    :    # Do pointless work
            pass
        this_is_a_very_long_line    = (     2, 4,    5,
             7, 9        )
        return     a+1


which is still ugly, but continues to work correctly. The only way to 
break working code by re-indenting in such a simple-minded fashion is if 
the layout of string literals is significant.

But of course no professional-quality re-indenter program would just do a 
simple-minded replace('  ', '    ') on the source code, any more than a 
professional-quality code beautifier for a brace language would just add 
newlines and spaces around every brace it saw.

A less simple-minded re-indenter would only replace *indentation*, not 
random whitespace. In that case, how could it break anything? Since the 
indents are correct, you are mapping indents of 2, 4, 6, 8, ... spaces to 
4, 8, 12, 16, .... What do you think will break?


If you start with broken indentation, it is difficult to fix, but that's 
not the OP's problem. In a brace language (whether you spell them { } or 
BEGIN END or START-BLOCK-HERE and END-BLOCK-HERE) if you start with 
inconsistent braces, it is equally difficult to fix. Invalid code is 
invalid code no matter what language you are using, and in general can't 
be mechanically fixed. If the nature of the breakage is such that the 
code is inconsistent or ambiguous, you need to *read* and *understand* it 
to fix it, no matter whether you have braces or indents.



-- 
Steven