marked-up Python code

[Diez B. Roggisch]

Luc Goossens wrote:

> Hi,
> 
> I would like to experiment with marked-up Python source code. A more
> elaborate explanation of the use-case is at the end of this mail. The
> short story is that I would like to do things like assign colors to
> pieces of text in my editor and have this information saved _in my
> source  code_
> smth like
> <red>
> else :
>   print "ERROR"
>   return -1
> </red>
> 
> "all" the Python parser has to do is skip the mark-up.
> 
> Has something like this been done before? Is there a way  to do this
> without changing the Python executable? If not, where in the source
> code should I start looking?
> 
> cheers,
> Luc
> 
> PS1
> I know I can put the mark-up after a # and the problem is solved
> trivially, but this will not work for all cases (e.g. mark-up of
> single identifiers) and to be honest I was thinking of recycling some
> mark-up capable editor and an existing mark-up language
> 
> PS2
> here's the real use case
> I have a small application in Python. The code shares a recurring
> feature: within methods 20% of the code lines is about the actual
> handling of the correct case, 40% is about the handling of the
> incorrect cases, 40% is instrumenting (logging and timing).
> A case for aspect oriented programming? I would certainly think so,
> but unfortunately  there is no obvious way to map this to the
> prevailing aspect-advice-joint point-point cut model. Moreover, I
> really do not want this code to become fragmented over multiple
> source code files, I just want the aspects to be readily visible in
> my editor, and be able to selectively show/hide some of them (like
> expanding/collapsing code blocks).

I'd do it like this:

if config.logging:
   <logging-related code>
if config.correct_case:
   <correct case code

Then alter your config.  Your approach will make you fight on two fronts:
python pre-processing to strip out code, working against the dynamicity of
the language and making you dependand on the preprocessor being available
under all circumstances (think of checking out the code on a remote
machine), and of course teaching the editor new tricks. 

instead using one standardized idiom as above might be sufficient to teach
an editor for convenience whilst keeping the source actual source.

Diez