[Python-ideas] Another indentation style

Rob Cliffe rob.cliffe at btinternet.com
Sun Sep 1 13:10:19 CEST 2013

On 01/09/2013 10:21, Steven D'Aprano wrote:
> On 01/09/13 18:31, Musical Notation wrote:
>> In Haskell, you can write:
>> let x=1
>>      y=2
>> In Python, why you can't write:
>> if True: x=x+1
>>           y=x
>> ?
> Because allowing that does not let you do anything different or new 
> that you couldn't do before, it would not make code any clearer or 
> more understandable, and it would decrease the readability of the code.
If I can be forgiven for slightly changing the subject (sorry, Musical 

Talking of unconventional ways of indenting:

In Python, writing multiple code statements on a single line, especially 
with a semi-colin, appears to be a taboo roughly on a par with appearing 
naked in public.  But I believe that there are times when it is the 
clearest way of writing code, viz. when it makes visually obvious a 
*pattern* in the code.
Here is one example, not very different from some "real" code that I wrote:

def test(condition, a, b):
     if condition=='equals'          : return a==b
     if condition=='is greater than' : return a>b
     if condition=='contains'        : return b in a
     if condition=='starts with'     : return a.startswith(b)

And here is some real code that I wrote (not worth explaining in 
detail).  I am sorry that it breaks another convention, having lines 
longer than 80 characters - this happens not be inconvenient for me, and 
was the best authentic *real* example I could find without spending a 
long time searching:

         assert PN[0].isalpha()    ; FirstPart  = PN[0] ; PN = 
PN[1:].lstrip(Seps) # Must be a letter
         if PN[0].isalpha()        : FirstPart += PN[0] ; PN = 
PN[1:].lstrip(Seps) # May be a second letter
         assert PN[0].isdigit()    ; FirstPart += PN[0] ; PN = 
PN[1:].lstrip(Seps) # Must be a digit
         if PN and PN[0].isalnum() : FirstPart += PN[0] ; PN = 
PN[1:]              # May be a letter or digit

(These examples look best with the colons/semicolons/equals 
signs/statements lined up vertically.  They will probably look ragged in 
an e-mail.  They should look as intended if they are cut and pasted into 
a (fixed-size font) editor.)

Writing the code like this makes apparent:
     (1) There is a pattern to the code.
     (2) Where the pattern is not quite consistent.  E.g. in my second 
example the first line contains "FirstPart  =", the other lines contain 
"FirstPart +=". *Seeing* this is half-way to understanding it.
     (3) The conceptual separation of the whole chunk of code from what 
precedes and what follows it (which can be emphasised by putting a blank 
line before and after it).
*None* of this would be so apparent if the code were written one 
statement per line.  (Is 'statement' the correct technical term?  Please 
correct me.)  There is also a minor advantage to writing fewer lines of 
code - you can see more of the program in one screenfull at a time.

(And: that you may find a smarter way of rewriting these specific 
examples is not really the point.  In my younger days I might have written:
     if wkday==0: return 'Monday'
     if wkday==1: return 'Tuesday'
Nowadays I would probably write something like
     return { 0 : 'Monday', 1 : 'Tuesday'  ... etc. }[wkday]
And you may have an even better way.
Again - not really the point.

Best wishes,
Rob Cliffe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130901/2301f7d3/attachment.html>

More information about the Python-ideas mailing list