Greg Wilson wrote:

...

...

Marc-Andre Lemburg: 1. Embed pragma declarations in comments: #pragma: name = value

2. Reusing a Python keyword to build a new form of statement: def name = value

3. Add a new keyword: decl name = value

...

Guido van Rossum: I say add a new reserved word pragma and accept the consequences. The other solutions are just too ugly.

Greg Wilson: Will pragma values be available at run-time, e.g. in a special module-level dictionary variable '__pragma__', so that:

pragma "encoding" = "UTF8" pragma "division" = "fractional"

has the same effect as:

__pragma__["encoding"] = "UTF8" __pragma__["division"] = "fractional"

If that's the case, would it be better to use the dictionary syntax? Or does the special form simplify pragma detection so much as to justify adding new syntax?

Pragmas tell the compiler to make certain assumptions about the scope they appear in. It may be useful have their values available as __pragma__ dict too, but only for introspection purposes and then only for objects which support the attribute. If we were to use a convention such as your proposed dictionary assignment for these purposes, the compiler would have to treat these assignments in special ways. Adding a new reserved word is much cleaner.

Also, what's the effect of putting a pragma in the middle of a file, rather than at the top? Does 'import' respect pragmas, or are they per-file? I've seen Fortran files that start with 20 lines of:

C$VENDOR PROPERTY DEFAULT

to disable any settings that might be in effect when the file is included in another, just so that the author of the include'd file could be sure of the semantics of the code he was writing.

The compiler will see the pragma definition as soon as it reaches it during compilation. All subsequent compilation (up to where the compilation block ends, i.e. up to module, function and class boundaries) will be influenced by the setting. This is in line with all other declarations in Python, e.g. those of global variables, functions and classes. Imports do not affect pragmas since pragmas are a compile time thing. Here are some possible applications of pragmas (just to toss in a few ideas): # Cause global lookups to be cached in function's locals for future # reuse. pragma globals = 'constant' # Cause all Unicode literals in the current scope to be # interpreted as UTF-8. pragma encoding = 'utf-8' # Use -OO style optimizations pragma optimization = 2 # Default division mode pragma division = 'float' The basic syntax in the above examples is: "pragma" NAME "=" (NUMBER | STRING+) It has to be that simple to allow the compiler use the information at compilation time. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

Skip Montanaro wrote:

MAL> Here are some possible applications of pragmas (just to toss in MAL> a few ideas):

MAL> # Cause global lookups to be cached in function's locals for future MAL> # reuse. MAL> pragma globals = 'constant'

MAL> # Cause all Unicode literals in the current scope to be MAL> # interpreted as UTF-8. MAL> pragma encoding = 'utf-8'

MAL> # Use -OO style optimizations MAL> pragma optimization = 2

MAL> # Default division mode MAL> pragma division = 'float'

Marc-Andre,

My interpretation of the word "pragma" (and I think a probably common interpretation) is that it is a "hint to the compiler" which the compiler can ignore if it chooses. See

http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?query=pragma

Your use of the word suggests that you propose to implement something more akin to a "directive", that is, something the compiler is not free to ignore. Ignoring the pragma in the first and third examples will likely only make the program run slower. Ignoring the second or fourth pragmas would likely result in incorrect compilation of the source.

Whatever you come up with, I think the distinction between hint and directive will have to be made clear in the documentation.

True, I see the pragma statement as directive. Perhaps its not the best name after all -- but then it is likely not to be in use in existing Python programs as identifier, so perhaps we just need to make it clear in the documentation that some pragma statements will carry important information, not only hints. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

Greg Wilson wrote:

If a mechanism for providing meta-information about code is going to be added to Python, then I would like it to be flexible enough for developers to define/add their own. It's just like allowing developers to extend the type system with new classes, rather than handing them a fixed set of built-in types and saying, "Good luck". (Most commercial Fortran compilers take the second approach, by providing a bunch of inflexible, vendor-specific pragmas. It's a nightmare...)

I don't think that Python will move in that direction. pragmas are really only meant to add some form of meta-information to a Python source file which would otherwise have to be passed to the compiler in order to produce correct output. It's merely a way of defining compile time flags for Python modules which allow more flexible compilation. Other tools might also make use of these pragmas, e.g. freeze, to allow inspection of a module without having to execute it.

I think that pragmas are essentially callbacks into the interpreter. When I put:

pragma encoding = "UTF-16"

I am telling the interpreter to execute its 'setEncoding()' method right away.

pragmas have a different target: they tell the compiler (or some other non-executing tool) to make a certain assumption about the code it is currently busy compiling. The compiler is not expected to execute any Python code when it sees a pragma, it will only set a few internal variables according to the values stated in the pragma or simply ignore it if the pragma uses an unknown key and then proceed with compiling.

So, why not present pragmas in that way? I.e., why not expose the Python interpreter as a callable object while the source is being parsed and compiled? I think that:

__python__.setEncoding("UTF-16")

is readable, and can be extended in lots of well-structured ways by exposing exactly as much of the interpreter as is deemed safe. Arguments could be restricted to constants, or built-in operations on constants, to start with, without compromising future extensibility.

The natural place for these APIs would be the sys module... no need for an extra __python__ module or object. I'd rather not add complicated semantics to pragmas -- they should be able to set flags, but not much more. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

Greg Wilson wrote:

...

Marc-Andre Lemburg wrote: I'd rather not add complicated semantics to pragmas -- they should be able to set flags, but not much more.

Greg Wilson writes:

That's probably what every Fortran compiler vendor said at first --- "just a couple of on/off flags". Then it was, "Set numeric values (like the debugging level)". A full-blown HPF compiler's pragmas are now a complete programming language, so that you can (for example) specify how to partition one array based on the partitioning in another.

Same thing happened with the C preprocessor --- more and more directives crept in over time. And the Microsoft C++ compiler. And I'm sure this list's readers could come up with dozens of more examples.

Pragmas are a way to give instructions to the interpreter; when you let people give something instructions, you're letting them program it, and I think it's best to design your mechanism from the start to support that.

I don't get your point: you can "program" the interpreter by calling various sys module APIs to set interpreter flags already. Pragmas are needed to tell the compiler what to do with a source file. They extend the command line flags which are already available to a more fine-grained mechanism. That's all -- nothing more. If a programmer wants to influence compilation globally, then she would have to set the sys module flags prior to invoking compile(). (This is already possible using mx.Tools additional sys builtins, e.g. you can tell the compiler to work in optimizing mode prior to invoking compile(). Some version of these will most likely go into 2.1.) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

Greg Wilson wrote:

...

...

...

Marc-Andre Lemburg wrote: I'd rather not add complicated semantics to pragmas -- they should be able to set flags, but not much more.

...

...

Greg Wilson writes: Pragmas are a way to give instructions to the interpreter; when you let people give something instructions, you're letting them program it, and I think it's best to design your mechanism from the start to support that.

...

Marc-Andre Lemburg: I don't get your point: you can "program" the interpreter by calling various sys module APIs to set interpreter flags already.

Pragmas are needed to tell the compiler what to do with a source file. They extend the command line flags which are already available to a more fine-grained mechanism. That's all -- nothing more.

Greg Wilson writes: I understand, but my experience with other languages indicates that once you have a way to set the parser's flags from within the source file being parsed, people are going to want to be able to do it conditionally, i.e. to set one flag based on the value of another. Then they're going to want to see if particular flags have been set to something other than their default values, and so on. Pragmas are a way to embed programs for the parser in the file being parsed. If we're going to allow this at all, we will save ourselves a lot of future grief by planning for this now.

I don't think mixing compilation with execution is a good idea. If we ever want to add this feature, we can always use a pragma for it ;-) ... def mysettings(compiler, locals, globals, target): compiler.setoptimization(2) # Call the above hook for every new compilation block pragma compiler_hook = "mysettings" -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

Greg Ewing:

Greg Wilson :

...

Pragmas are a way to embed programs for the parser in the file being parsed.

I hope the BDFL has the good sense to run screaming from anything that has the word "pragma" in it. As this discussion demonstrates, it's far too fuzzy and open-ended a concept -- nobody can agree on what sort of thing a pragma is supposed to be.

It is a good idea, however, to claim a piece of syntactic turf as early as possible so that if/when it is needed, it is unlikely to cause problems with previously written code. My preference would be to introduce a reserved word 'directive' for future expansion here. 'pragma' has connotations of 'ignorable compiler hint' but most of the proposed compiler directives will cause incorrect behaviour if ignored. Neil

"M.-A. Lemburg" :

If it's just the word itself that's bugging you, then we can have a separate discussion on that. Perhaps "assume" or "declare" would be a better candidates.

Yes, "declare" would be better. ALthough I'm still somewhat uncomfortable with the idea of naming a language feature before having a concrete example of what it's going to be used for. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+

mal wrote:

I gave some examples in the other pragma thread. The main idea behind "declare" is to define flags at compilation time, the encoding of string literals being one of the original motivations for introducing these flags:

declare encoding = "latin-1" x = u"This text will be interpreted as Latin-1 and stored as Unicode"

declare encoding = "ascii" y = u"This is supposed to be ASCII, but contains äöü Umlauts - error !"

-1 for sanity's sake, we should only allow a *single* encoding per source file. anything else is madness. besides, the goal should be to apply the encoding to the entire file, not just the contents of string literals. (hint: how many editing and display environments support multiple encodings per text file?) </F>