[Python-Dev] python syntax additions to support indentation insensitivity/generated code

Ben Wing ben at 666.com
Mon May 1 06:42:13 CEST 2006


recently i've been writing code that generates a python program from a 
source file containing intermixed python code and non-python constructs, 
which get converted into python.

similar things have been done in many other languages -- consider, for 
example, the way php is embedded into web pages.

unfortunately, doing this is really hard in python because of its 
whitespace sensitivity.

i suggest the following simple change: in addition to constructs like this:

block:
  within-block statement
  within-block statement
  ...
out-of-block statement

python should support

block::
  within-block statement
  within-block statement
  ...
end
out-of-block statement

the syntax is similar, but has an extra colon, and is terminated by an 
`end'.  indentation of immediate-level statements within the block is 
unimportant.

mixed-mode code should be possible, e.g.:

block-1::
  within-block-1 statement
  within-block-1 statement
  block-2:
    within-block-2 statement
    within-block-2 statement
  within-block-1 statement
  ...
end

in other words, code within block-2 is indentation-sensitive; block-2 is 
terminated by the first immediate-level statement at or below the 
indentation of the `block-2' statement. 

similarly, in this:

[A] block-1::
[B]   within-block-1 statement
[C]   within-block-1 statement
[D]   block-2:
[E]     within-block-2 statement
[F]     within-block-2 statement
[G]     block-3::
[H]       within-block-3 statement
[I]       within-block-3 statement
[J]     end
[K]     within-block-2 statement
[L]   within-block-1 statement
[M]   ...
[N] end

the indentation of lines [D], [E], [F], [G], [K] and [L]  is 
significant, but not any others.  that is, [E], [F], [G], and [K] must 
be at the same level, which is greater than the level of line [D], and 
line [L] must be at a level less than or equal to line [D].  all other 
lines, including [H], [I] and [J], can be at any indentation level.  
also, line [D] can be at any level with respect to line [C].

the idea is that a python code generator could easily mix generated and 
hand-written code.  hand-written code written in normal python style 
could be wrapped by generated code using the indentation-insensitive 
style; if the generated code had no indentation, everything would work 
as expected without the generator having to worry about indentation.

i don't see too many problems with backward-compatibility here.  the 
double-colon shouldn't cause any problems, since that syntax isn't legal 
currently.  `end' could be recognized as a keyword only following a 
double-colon block; elsewhere, it could still be a variable.

ben



More information about the Python-Dev mailing list