[Python-Dev] #pragmas in Python source code

M.-A. Lemburg mal@lemburg.com
Wed, 12 Apr 2000 17:52:34 +0200


"Fred L. Drake, Jr." wrote:
> 
> M.-A. Lemburg writes:
>  > Here's a simple strawman for the syntax:
> ...
>  > The compiler would scan these pragma defs, add them to an
>  > internal temporary dictionary and use them for all subsequent
>  > code it finds during the compilation process. The dictionary
>  > would have to stay around until the original compile() call has
>  > completed (spanning recursive calls).
> 
> Marc-Andre,
>   The problem with this proposal is that the pragmas are embedded in
> the comments; I'd rather see a new keyword and statement.  It could be
> defined something like:
> 
> pragma_atom: NAME | NUMBER | STRING+
> pragma_stmt: 'pragma' NAME ':' pragma_atom (',' pragma_atom)*
> 
>   The biggest problem with embedding it in comments is that it is no
> longer part of the syntax tree generated by the parser.  The pragmas
> become global to the module on a de-facto basis.  While this is
> probably reasonable for the sorts of pragmas we've thought of so far,
> this seems an unnecessary restriction; future tools may support scoped
> pragmas to help out with selection of optimization strategies, for
> instance, or other applications.

Fine with me, but this probably isn't going to make it into
1.7 and I don't want to wait until Py3K... perhaps there is
another way to implement this without adding a new keyword,
e.g. we could first use some kind of hack to implement 
"# pragma ..." and then later on allow dropping the "#"
to make full use of the new mechanism.

>   If we were to go with a strictly global view of pragmas, we'd need
> to expose the dictionary created by the parser.  The parser module
> would need to be able to expose the dictionary and accept a dictionary
> when receiving a parse tree for compilation.  The internals just can't
> be *too* internal!  ;)

True :-)

BTW, while poking around in the tokenizer/compiler I found
a serious bug in the way concatenated strings are implemented:
right now the compiler expects to always find string objects,
yet it could just as well receive Unicode objects or even
mixed string and Unicode objects.

Try it: u = (u"abc" u"abc") dumps core !

I'll fix this with the next patch set.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/