
A couple of other threads started me to thinking that there are a couple of things missing from our warnings framework. Many languages have pragmas that allow you turn warnings on and off in code. For instance, I should be able to put a pragma at the top of a module that uses string functions to say: "I know that this module doesn't adhere to the latest Python conventions. Please don't warn me about it." I should also be able to put a declaration that says: "I'm really paranoid about shadowing globals and builtins. Please warn me when I do that." Batch and visual linters could also use the declarations to customize their behaviors. And of course we have a stack of other features that could use pragmas: * type signatures * Unicode syntax declarations * external object model language binding hints * ... A case could be made that warning pragmas could use a totally different syntax from "user-defined" pragmas. I don't care much. Paul

Paul Prescod wrote:
There was a long thread about this some months ago. We agreed to add a new keyword to the language (I think it was "define") which then uses a very simple syntax which can be interpreted at compile time to modify the behaviour of the compiler, e.g. define <identifier> = <literal> There was also a discussion about allowing limited forms of expressions instead of the constant literal. define source_encoding = "utf-8" was the original motivation for this, but (as always ;) the usefulness for other application areas was quickly recognized, e.g. to enable compilation in optimization mode on a per module basis. PS: "define" is perhaps not obscure enough as keyword... -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

There was a long thread about this some months ago. We agreed to add a new keyword to the language (I think it was "define")
I don't recall agreeing. :-) This is PEP material. For 2.2, please! --Guido van Rossum (home page: http://www.python.org/~guido/)

Guido van Rossum wrote:
Well, maybe it was a misinterpretation on my part... you said something like "add a new keyword and live with the consequences". AFAIR, of course :-)
This is PEP material. For 2.2, please!
Ok. -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

Paul Prescod wrote:
There was a long thread about this some months ago. We agreed to add a new keyword to the language (I think it was "define") which then uses a very simple syntax which can be interpreted at compile time to modify the behaviour of the compiler, e.g. define <identifier> = <literal> There was also a discussion about allowing limited forms of expressions instead of the constant literal. define source_encoding = "utf-8" was the original motivation for this, but (as always ;) the usefulness for other application areas was quickly recognized, e.g. to enable compilation in optimization mode on a per module basis. PS: "define" is perhaps not obscure enough as keyword... -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

There was a long thread about this some months ago. We agreed to add a new keyword to the language (I think it was "define")
I don't recall agreeing. :-) This is PEP material. For 2.2, please! --Guido van Rossum (home page: http://www.python.org/~guido/)

Guido van Rossum wrote:
Well, maybe it was a misinterpretation on my part... you said something like "add a new keyword and live with the consequences". AFAIR, of course :-)
This is PEP material. For 2.2, please!
Ok. -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
participants (3)
-
Guido van Rossum
-
M.-A. Lemburg
-
Paul Prescod