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