Pragma-style declaration syntax

I've been tossing some ideas around w/r to adding pragma style declarations to Python and would like to hear what you think about these: 1. Embed pragma declarations in comments: #pragma: name = value Problem: comments are removed by the tokenizer, yet the compiler will have to make use of them, so some logic would be needed to carry them along. 2. Reusing a Python keyword to build a new form of statement: def name = value Problem: not sure whether the compiler and grammar could handle this. The nice thing about this kind of declaration is that it would generate a node which the compiler could actively use. Furthermore, scoping would come for free. This one is my favourite. 3. Add a new keyword: decl name = value Problem: possible code breakage. This is only a question regarding the syntax of these meta- information declarations. The semantics remain to be solved in a different discussion. Comments ? Thanks, -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

I say add a new reserved word pragma and accept the consequences. The other solutions are just too ugly. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)

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? 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. Thanks, Greg

Greg Wilson wrote:
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.
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/

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. Skip

Skip Montanaro wrote:
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/

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 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. 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. Greg

Greg Wilson wrote:
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.
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.
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 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. Greg "oh no, not another parallelization directive" Wilson

Greg Wilson wrote:
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 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. Thanks, Greg

Greg Wilson wrote:
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 Wilson <gvwilson@nevex.com>:
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. INTERVIEWER: Tell us how you came to be drawn into the world of pragmas. COMPILER WRITER: Well, it started off with little things. Just a few boolean flags, a way to turn asserts on and off, debug output, that sort of thing. I thought, what harm can it do? It's not like I'm doing anything you couldn't do with command line switches, right? Then it got a little bit heavier, integer values for optimisation levels, even the odd string or two. Before I knew it I was doing the real hard stuff, constant expressions, conditionals, the whole shooting box. Then one day when I put in a hook for making arbitrary calls into the interpreter, that was when I finally realised I had a problem... 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 +--------------------------------------+

Greg Ewing:
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

Neil Hodgson wrote:
The objectives the "pragma" statement follows should be clear by now. 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. We need some kind of logic of this sort in Python. Otherhwise important features like source code encoding will not be possible. As I said before, I'm not advertising adding compiler programs to Python, just a simple way of passing information for the compiler. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

"M.-A. Lemburg" <mal@lemburg.com>:
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 +--------------------------------------+

Greg Ewing 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 !" A similar approach could be done for 8-bit string literals provided that the default encoding allows storing the decoded values. Say the default encoding is "utf-8", then you could write: declare encoding = "latin-1" x = "These are the German Umlauts: äöü" # x would the be assigned the corresponding UTF-8 value of that string Another motivation for using these flags is providing the compiler with information about possible assumptions it can make: declare globals = "constant" The compiler can then add code which caches all global lookups in locals for subsequent use. The reason I'm advertising a new keyword is that we need a way to tell the compiler about these things from within the source file. This is currently not possible, but is needed to allow different modules (from possibly different authors) to work together without the need to adapt their source files. Which flags will actually become available is left to a different discussion. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

mal wrote:
-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>

Fredrik Lundh wrote:
On the "declare" concept or just the above examples ?
for sanity's sake, we should only allow a *single* encoding per source file. anything else is madness.
Uhm, the above was meant as two *separate* examples. I completely agree that multiple encodings per file should not be allowed (this would be easy to implement in the compiler).
besides, the goal should be to apply the encoding to the entire file, not just the contents of string literals.
I'm not sure this is a good idea. The only parts where the encoding matters are string literals (unless I've overlooked some important detail). All other parts which could contain non-ASCII text such as comments are not seen by the compiler. So all source code encodings should really be ASCII supersets (even if just to make editing them using a plain 8-bit editor sane). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

I say add a new reserved word pragma and accept the consequences. The other solutions are just too ugly. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)

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? 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. Thanks, Greg

Greg Wilson wrote:
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.
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/

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. Skip

Skip Montanaro wrote:
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/

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 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. 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. Greg

Greg Wilson wrote:
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.
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.
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 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. Greg "oh no, not another parallelization directive" Wilson

Greg Wilson wrote:
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 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. Thanks, Greg

Greg Wilson wrote:
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 Wilson <gvwilson@nevex.com>:
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. INTERVIEWER: Tell us how you came to be drawn into the world of pragmas. COMPILER WRITER: Well, it started off with little things. Just a few boolean flags, a way to turn asserts on and off, debug output, that sort of thing. I thought, what harm can it do? It's not like I'm doing anything you couldn't do with command line switches, right? Then it got a little bit heavier, integer values for optimisation levels, even the odd string or two. Before I knew it I was doing the real hard stuff, constant expressions, conditionals, the whole shooting box. Then one day when I put in a hook for making arbitrary calls into the interpreter, that was when I finally realised I had a problem... 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 +--------------------------------------+

Greg Ewing:
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

Neil Hodgson wrote:
The objectives the "pragma" statement follows should be clear by now. 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. We need some kind of logic of this sort in Python. Otherhwise important features like source code encoding will not be possible. As I said before, I'm not advertising adding compiler programs to Python, just a simple way of passing information for the compiler. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

"M.-A. Lemburg" <mal@lemburg.com>:
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 +--------------------------------------+

Greg Ewing 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 !" A similar approach could be done for 8-bit string literals provided that the default encoding allows storing the decoded values. Say the default encoding is "utf-8", then you could write: declare encoding = "latin-1" x = "These are the German Umlauts: äöü" # x would the be assigned the corresponding UTF-8 value of that string Another motivation for using these flags is providing the compiler with information about possible assumptions it can make: declare globals = "constant" The compiler can then add code which caches all global lookups in locals for subsequent use. The reason I'm advertising a new keyword is that we need a way to tell the compiler about these things from within the source file. This is currently not possible, but is needed to allow different modules (from possibly different authors) to work together without the need to adapt their source files. Which flags will actually become available is left to a different discussion. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

mal wrote:
-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>

Fredrik Lundh wrote:
On the "declare" concept or just the above examples ?
for sanity's sake, we should only allow a *single* encoding per source file. anything else is madness.
Uhm, the above was meant as two *separate* examples. I completely agree that multiple encodings per file should not be allowed (this would be easy to implement in the compiler).
besides, the goal should be to apply the encoding to the entire file, not just the contents of string literals.
I'm not sure this is a good idea. The only parts where the encoding matters are string literals (unless I've overlooked some important detail). All other parts which could contain non-ASCII text such as comments are not seen by the compiler. So all source code encodings should really be ASCII supersets (even if just to make editing them using a plain 8-bit editor sane). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
participants (7)
-
Fredrik Lundh
-
Greg Ewing
-
Greg Wilson
-
Guido van Rossum
-
M.-A. Lemburg
-
Neil Hodgson
-
Skip Montanaro