Compiler directives in the source

Dale Strickland-Clark dale at riverhall.NOTHANKS.co.uk
Wed Feb 5 12:33:34 EST 2003


The earlier discussion on coding directives in comments got me
thinking.

In case you missed it, the following two posts summarise it quite
nicely for me:

>Paul Rubin <phr-n2003b at NOSPAMnightsong.com> wrote:
>
>>Brian Quinlan <brian at sweetapp.com> writes:
>>> Just add:
>>> # -*- coding: Latin-1 -*-
>>> 
>>> to the top of your source files and you will be fine.
>>
>>What is this nonsense?  The interpreter is reading comment text now?
>>Yucch!

There is a general need for passing information to the compiler that
hasn't been addressed by this horrible magic comment.

I think the following compiler options would be usefully avilable as
directives in the source as well as on the command line:

-O     : optimize generated bytecode 
-OO    : remove doc-strings in addition to the -O optimizations
-Q arg : division options:
-S     : don't imply 'import site' on initialization
-v     : verbose (trace import statements) (also PYTHONVERBOSE=x)
-W arg : warning control 
-x     : skip first line of source

To that list, I would like to add:

debug arg : control value of __debug__ and assert() (independent of
            optimisation)

Just about any non alpha-character in column 1 could be unambiguously
applied as a signal character, with a few obvious exceptions
including: #, (, [, tab and space. So what about % ?

That would give us a set of compiler directives like these:

%optimize off | on | full
%division old | warn |new
%importsite off | on
%verbose off | on
%warnings arg
%skip 1
%debug off | on
%ignorecase off | on     (like PYTHONCASEOK)
%path dir;dir...         (like PYTHONPATH)
%home dir                (like PYTHONHOME)

The skip option is a bit of a tease as the option would have to appear
after the line to be skipped but much more useful than on the command
line.

A rule that the first non-directive (excluding first line where "skip
1") marked the end of the directives would be acceptable and would
simplify the handling.

Advantages: Flexible and easily extended. Easier to remember. Simple
syntax. Comments stay as comments. 

Disadvantages: Too late? Bigger code change?


--
Dale Strickland-Clark
Riverhall Systems Ltd




More information about the Python-list mailing list