Warning Framework (PEP 230)
I'm maybe about three quarters on the way with writing PEP 230 -- far enough along to be asking for comments. Get it from CVS or go to: http://python.sourceforge.net/peps/pep-0230.html A prototype implementation in Python is included in the PEP; I think this shows that the implementation is not too complex (Paul Prescod's fear about my proposal). This is pretty close to what I proposed earlier (Nov 5), except that I have added warning category classes (inspired by Paul's proposal). This class also serves as the exception to be raised when warnings are turned into exceptions. Do I need to include a discussion of Paul's counter-proposal and why I rejected it? --Guido van Rossum (home page: http://www.python.org/~guido/)
Nobody seems to care much about the warnings PEP so far. What's up? Are you all too busy buying presents for the holidays? Then get me some too, please? :-)
I've now produced a prototype implementation for the C code: http://sourceforge.net/patch/?func=detailpatch&patch_id=102715&group_id=5470 Issues: - This defines a C API PyErr_Warn(category, message) instead of Py_Warn(message, category) as the PEP proposes. I actually like this better: it's consistent with PyErr_SetString() etc. rather than with the Python warn(message[, category]) function. - This calls the Python module from C. We'll have to see if this is fast enough. I wish I could postpone the import of warnings.py until the first call to PyErr_Warn(), but unfortunately the warning category classes must be initialized first (so they can be passed into PyErr_Warn()). The current version of warnings.py imports rather a lot of other modules (e.g. re and getopt); this can be reduced by placing those imports inside the functions that use them. - All the issues listed in the PEP. Please comment! BTW: somebody overwrote the PEP on SourceForge with an older version. Please remember to do a "cvs update" before running "make install" in the peps directory! --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
My opinions: * it should be a built-in or keyword, not a function in "sys". Warning is supposed to be as easy as possible so people will do it often. <irrelevant_aside>sys.argv and sys.stdout annoy me as it is.</> * the term "level" applied to warnings typically means "warning level" as in -W1 -W2 -Wall. Proposal: call it "stacklevel" or something. * this level idea gives rise to another question. What if I want to see the full stack context of a warning? Do I have to implement a whole new warning output hook? It seems like I should be able to specify this as a command line option alongside the action. * I prefer ":*:*:" to ":::" for leaving parts of the warning spec out. * should there be a sys.formatwarning? What if I want to redirect warnings to a socket -- I'd like to use the standard formatting machinery. Or vice versa, I might want to change the formatting but not override the destination. * there should be a "RuntimeWarning" -- base category for warnings about dubious runtime behaviors (e.g. integer division truncated value) * it should be possible to strip warnings as an optimization step. That may require interpreter and syntax support. * warnings will usually be tied to tests which the user will want to be able to optimize out also. (e.g. if __debug__ and type(foo)==StringType: warn "Should be Unicode!") I propose: >>> warn conditional, message[, category] to be very parallel with >>> assert conditional, message I'm not proposing the use of the assert keyword anymore, but I am trying to reuse the syntax for familiarity. Perhaps -Wstrip would strip warnings out of the bytecode. Paul Prescod
Disagree. Warnings are there mostly for the Python system to warn the Python programmer. The most heavy use will come from the standard library, not from user code.
<irrelevant_aside>sys.argv and sys.stdout annoy me as it is.</>
Too bad.
* the term "level" applied to warnings typically means "warning level" as in -W1 -W2 -Wall. Proposal: call it "stacklevel" or something.
Good point.
Turn warnings into errors and you'll get a full traceback. If you really want a full traceback without exiting, some creative use of sys._getframe() and the traceback module will probably suit you well.
* I prefer ":*:*:" to ":::" for leaving parts of the warning spec out.
I don't.
Good point. I'm changing this to: def showwarning(message, category, filename, lineno, file=None): """Hook to frite a warning to a file; replace if you like.""" and def formatwarning(message, category, filename, lineno): """Hook to format a warning the standard way."""
* there should be a "RuntimeWarning" -- base category for warnings about dubious runtime behaviors (e.g. integer division truncated value)
OK.
* it should be possible to strip warnings as an optimization step. That may require interpreter and syntax support.
I don't see the point of this. I think this comes from our different views on who should issue warnings.
Sorry, this is not worth a new keyword.
Why? --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
Most Python code is part of some library or another. It may not be the standard library but its still a library. Perl and Java both make warnings (especially about deprecation) very easy *for user code*.
Everyone who creates a reusable library will want to issue warnings. That is to say, most serious Python programmers. Anyhow, let's presume that it is only the standard library that issues warnings (for arguments sake). What if I have a speed-critical module that triggers warnings in an inner loop. Turning off the warning doesn't turn off the overhead of the warning infrastructure. I should be able to turn off the overhead easily -- ideally from the Python command line. And I still feel that part of that "overhead" is in the code that tests to determine whether to issue the warnings. There should be a way to turn off that overhead also. Paul
[me]
[Paul Prescod]
Hey. I'm not making it impossible to use warnings. I'm making it very easy. All you have to do is put "from warnings import warn" at the top of your library module. Requesting a built-in or even a new statement is simply excessive.
So rewrite your code so that it doesn't trigger the warning. When you get a warning, you're doing something that could be done in a better way. So don't whine about the performance. It's a quality of implementation issue whether C code that tests for issues that deserve warnings can do the test without slowing down code that doesn't deserve a warning. Ditto for standard library code. Here's an example. I expect there will eventually (not in 2.1 yet!) warnings in the deprecated string module. If you get such a warning in a time-critical piece of code, the solution is to use string methods -- not to while about the performance of the backwards compatibility code. --Guido van Rossum (home page: http://www.python.org/~guido/)
Some of my thoughts after reading the PEP and Paul/Guido's exchange. - A function in the warn module is better than one in the sys module. "from warnings import warn" is good enough to not warrant a built-in. I get the sense that the PEP description is behind Guido's currently implementation here. - When PyErr_Warn() returns 1, does that mean a warning has been transmuted into an exception, or some other exception occurred during the setting of the warning? (I think I know, but the PEP could be clearer here). - It would be nice if lineno can be a range specification. Other matches are based on regexps -- think of this as a line number regexp. - Why not do setupwarnings() in site.py? - Regexp matching on messages should be case insensitive. - The second argument to sys.warn() or PyErr_Warn() can be any class, right? If so, it's easy for me to have my own warning classes. What if I want to set up my own warnings filters? Maybe if `action' could be a callable as well as a string. Then in my IDE, I could set that to "mygui.popupWarningsDialog". -Barry
Yes. I've updated the PEP to match the (2nd) implementation.
I've clarified this now: it returns 1 in either case. You have to do exception handling in either case. I'm not telling why -- you don't need to know. The caller of PyErr_Warn() should not attempt to catch the exception -- if that's your intent, you shouldn't be calling PyErr_Warn(). And PyErr_Warn() is complicated enough that it has to allow raising an exception.
Too much complexity already.
- Why not do setupwarnings() in site.py?
See the PEP and the current implementation. The delayed-loading of the warnings module means that we have to save the -W options as sys.warnoptions. (This also makes them work when multiple interpreters are used -- they all get the -W options.)
- Regexp matching on messages should be case insensitive.
Good point! Done in my version of the code.
- The second argument to sys.warn() or PyErr_Warn() can be any class, right?
Almost. It must be derived from __builtin__.Warning.
No, for that purpose you would override warnings.showwarning(). --Guido van Rossum (home page: http://www.python.org/~guido/)
"GvR" == Guido van Rossum <guido@python.org> writes:
GvR> I've clarified this now: it returns 1 in either case. You GvR> have to do exception handling in either case. I'm not GvR> telling why -- you don't need to know. The caller of GvR> PyErr_Warn() should not attempt to catch the exception -- if GvR> that's your intent, you shouldn't be calling PyErr_Warn(). GvR> And PyErr_Warn() is complicated enough that it has to allow GvR> raising an exception. Makes sense. >> - It would be nice if lineno can be a range specification. >> Other matches are based on regexps -- think of this as a line >> number regexp. GvR> Too much complexity already. Okay, no biggie I think. >> - Why not do setupwarnings() in site.py? GvR> See the PEP and the current implementation. The GvR> delayed-loading of the warnings module means that we have to GvR> save the -W options as sys.warnoptions. (This also makes GvR> them work when multiple interpreters are used -- they all get GvR> the -W options.) Cool. >> - Regexp matching on messages should be case insensitive. GvR> Good point! Done in my version of the code. Cool. >> - The second argument to sys.warn() or PyErr_Warn() can be any >> class, right? GvR> Almost. It must be derived from __builtin__.Warning. __builtin__.Warning == exceptions.Warning, right? >> If so, it's easy for me to have my own warning classes. What >> if I want to set up my own warnings filters? Maybe if `action' >> could be a callable as well as a string. Then in my IDE, I >> could set that to "mygui.popupWarningsDialog". GvR> No, for that purpose you would override GvR> warnings.showwarning(). Cool. Looks good. -Barry
On Mon, Dec 11, 2000 at 11:53:37AM -0500, Guido van Rossum wrote:
Since you must do "from warnings import warn" before using the warnings, then I think it makes sense to put the Warning classes into the warnings module. (e.g. why increase the size of the builtins?) Cheers, -g -- Greg Stein, http://www.lyra.org/
I don't particularly care whether the Warning category classes are builtins, but I can't declare them in the warnings module. Typical use from C is: if (PyErr_Warn(PyExc_DeprecationWarning, "the strop module is deprecated")) return NULL; PyErr_Warn() imports the warnings module on its first call. But the value of PyExc_DeprecationWarning c.s. must be available *before* the first call, so they can't be imported from the warnings module! My first version imported warnings at the start of the program, but this almost doubled the start-up time, hence the design where the module is imported only when needed. The most convenient place to create the Warning category classes is in the _exceptions module; doing it the easiest way there means that they are automatically exported to __builtin__. This doesn't bother me enough to try and hide them. --Guido van Rossum (home page: http://www.python.org/~guido/)
On Mon, Dec 11, 2000 at 07:39:31PM -0500, Guido van Rossum wrote:
Do the following: pywarn.h or pyerrors.h: #define PyWARN_DEPRECATION "DeprecationWarning" ... if (PyErr_Warn(PyWARN_DEPRECATION, "the strop module is deprecated")) return NULL; The PyErr_Warn would then use the string to dynamically look up / bind to the correct value from the warnings module. By using the symbolic constant, you will catch typos in the C code (e.g. if people passed raw strings, then a typo won't be found until runtime; using symbols will catch the problem at compile time). The above strategy will allow for fully-delayed loading, and for all the warnings to be located in the "warnings" module. Cheers, -g -- Greg Stein, http://www.lyra.org/
Yeah, that would be a possibility, if it was deemed evil that the warnings appear in __builtin__. I don't see what's so evil about that. (There's also the problem that the C code must be able to create new warning categories, as long as they are derived from the Warning base class. Your approach above doesn't support this. I'm sure you can figure a way around that too. But I prefer to hear why you think it's needed first.) --Guido van Rossum (home page: http://www.python.org/~guido/)
On Mon, Dec 11, 2000 at 08:21:41PM -0500, Guido van Rossum wrote:
I'm just attempting to avoid dumping more names into __builtins__ is all. I don't believe there is anything intrinsically bad about putting more names in there, but avoiding the kitchen-sink metaphor for __builtins__ has got to be a Good Thing :-) Cheers, -g -- Greg Stein, http://www.lyra.org/
On Mon, Dec 11, 2000 at 11:02:29AM -0500, Barry A. Warsaw wrote:
+1 on this. I have a response to Guido's first posted PEP on my laptop, but due to a weekend in Germany wasn't able to post it before he updated the PEP. I guess I can delete the arguments for this, now ;) but lets just say I think 'sys' is being a bit overused, and the case of a function in sys and its data in another module is just plain silly.
How about returning 1 for 'warning turned into exception' and -1 for 'normal exception' ? It would be slightly more similar to other functions if '-1' meant 'exception', and it would be easy to put in an if statement -- and still allow C code to ignore the produced error, if it wanted to.
+0 on this... I'm not sure if such fine-grained control is really necessary. I liked the hint at 'per function' granularity, but I realise it's tricky to do right, what with naming issues and all that.
- Regexp matching on messages should be case insensitive.
How about being able to pass in compiled regexp objects as well as strings ? I haven't looked at the implementation at all, so I'm not sure how expensive it would be, but it might also be nice to have users (= programmers) pass in an object with its own 'match' method, so you can 'interactively' decide whether or not to raise an exception, popup a window, and what not. Sort of like letting 'action' be a callable, which I think is a good idea as well. -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
Why would you want this? The user clearly said that they wanted the exception! --Guido van Rossum (home page: http://www.python.org/~guido/)
On Mon, Dec 11, 2000 at 12:11:02PM -0500, Guido van Rossum wrote:
Why would you want this? The user clearly said that they wanted the exception!
The difference is that in one case, the user will see the original warning-turned-exception, and in the other she won't -- the warning will be lost. At best she'll see (by looking at the traceback) the code intended to give a warning (that might or might not have been turned into an exception) and failed. The warning code might decide to do something aditional to notify the user of the thing it intended to warn about, which ended up as a 'real' exception because of something else. It's no biggy, obviously, except that if you change your mind it will be hard to add it without breaking code. Even if you explicitly state the return value should be tested for boolean value, not greater-than-zero value. -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
Yes -- this is a standard convention in Python. if there's a bug in code that is used to raise or handle an exception, you get a traceback from that bug.
Nah. The warning code shouldn't worry about that. If there's a bug in PyErr_Warn(), that should get top priority until it's fixed. --Guido van Rossum (home page: http://www.python.org/~guido/)
I've checked in the essential parts of the warnings PEP, and closed the SF patch. I haven't checked in the examples in the patch -- it's too early for that. But I figured that it's easier to revise the code once it's checked in. I'm pretty confident that it works as advertised. Still missing is documentation: the warnings module, the new API functions, and the new command line option should all be documented. I'll work on that over the holidays. I consider the PEP done. --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum writes:
I've assigned a bug to you in case you forget. I've given it a "show-stopper" priority level, so I'll feel good ripping the code out if you don't get docs written in time. ;-) -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Digital Creations
Nobody seems to care much about the warnings PEP so far. What's up? Are you all too busy buying presents for the holidays? Then get me some too, please? :-)
I've now produced a prototype implementation for the C code: http://sourceforge.net/patch/?func=detailpatch&patch_id=102715&group_id=5470 Issues: - This defines a C API PyErr_Warn(category, message) instead of Py_Warn(message, category) as the PEP proposes. I actually like this better: it's consistent with PyErr_SetString() etc. rather than with the Python warn(message[, category]) function. - This calls the Python module from C. We'll have to see if this is fast enough. I wish I could postpone the import of warnings.py until the first call to PyErr_Warn(), but unfortunately the warning category classes must be initialized first (so they can be passed into PyErr_Warn()). The current version of warnings.py imports rather a lot of other modules (e.g. re and getopt); this can be reduced by placing those imports inside the functions that use them. - All the issues listed in the PEP. Please comment! BTW: somebody overwrote the PEP on SourceForge with an older version. Please remember to do a "cvs update" before running "make install" in the peps directory! --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
My opinions: * it should be a built-in or keyword, not a function in "sys". Warning is supposed to be as easy as possible so people will do it often. <irrelevant_aside>sys.argv and sys.stdout annoy me as it is.</> * the term "level" applied to warnings typically means "warning level" as in -W1 -W2 -Wall. Proposal: call it "stacklevel" or something. * this level idea gives rise to another question. What if I want to see the full stack context of a warning? Do I have to implement a whole new warning output hook? It seems like I should be able to specify this as a command line option alongside the action. * I prefer ":*:*:" to ":::" for leaving parts of the warning spec out. * should there be a sys.formatwarning? What if I want to redirect warnings to a socket -- I'd like to use the standard formatting machinery. Or vice versa, I might want to change the formatting but not override the destination. * there should be a "RuntimeWarning" -- base category for warnings about dubious runtime behaviors (e.g. integer division truncated value) * it should be possible to strip warnings as an optimization step. That may require interpreter and syntax support. * warnings will usually be tied to tests which the user will want to be able to optimize out also. (e.g. if __debug__ and type(foo)==StringType: warn "Should be Unicode!") I propose: >>> warn conditional, message[, category] to be very parallel with >>> assert conditional, message I'm not proposing the use of the assert keyword anymore, but I am trying to reuse the syntax for familiarity. Perhaps -Wstrip would strip warnings out of the bytecode. Paul Prescod
Disagree. Warnings are there mostly for the Python system to warn the Python programmer. The most heavy use will come from the standard library, not from user code.
<irrelevant_aside>sys.argv and sys.stdout annoy me as it is.</>
Too bad.
* the term "level" applied to warnings typically means "warning level" as in -W1 -W2 -Wall. Proposal: call it "stacklevel" or something.
Good point.
Turn warnings into errors and you'll get a full traceback. If you really want a full traceback without exiting, some creative use of sys._getframe() and the traceback module will probably suit you well.
* I prefer ":*:*:" to ":::" for leaving parts of the warning spec out.
I don't.
Good point. I'm changing this to: def showwarning(message, category, filename, lineno, file=None): """Hook to frite a warning to a file; replace if you like.""" and def formatwarning(message, category, filename, lineno): """Hook to format a warning the standard way."""
* there should be a "RuntimeWarning" -- base category for warnings about dubious runtime behaviors (e.g. integer division truncated value)
OK.
* it should be possible to strip warnings as an optimization step. That may require interpreter and syntax support.
I don't see the point of this. I think this comes from our different views on who should issue warnings.
Sorry, this is not worth a new keyword.
Why? --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
Most Python code is part of some library or another. It may not be the standard library but its still a library. Perl and Java both make warnings (especially about deprecation) very easy *for user code*.
Everyone who creates a reusable library will want to issue warnings. That is to say, most serious Python programmers. Anyhow, let's presume that it is only the standard library that issues warnings (for arguments sake). What if I have a speed-critical module that triggers warnings in an inner loop. Turning off the warning doesn't turn off the overhead of the warning infrastructure. I should be able to turn off the overhead easily -- ideally from the Python command line. And I still feel that part of that "overhead" is in the code that tests to determine whether to issue the warnings. There should be a way to turn off that overhead also. Paul
[me]
[Paul Prescod]
Hey. I'm not making it impossible to use warnings. I'm making it very easy. All you have to do is put "from warnings import warn" at the top of your library module. Requesting a built-in or even a new statement is simply excessive.
So rewrite your code so that it doesn't trigger the warning. When you get a warning, you're doing something that could be done in a better way. So don't whine about the performance. It's a quality of implementation issue whether C code that tests for issues that deserve warnings can do the test without slowing down code that doesn't deserve a warning. Ditto for standard library code. Here's an example. I expect there will eventually (not in 2.1 yet!) warnings in the deprecated string module. If you get such a warning in a time-critical piece of code, the solution is to use string methods -- not to while about the performance of the backwards compatibility code. --Guido van Rossum (home page: http://www.python.org/~guido/)
Some of my thoughts after reading the PEP and Paul/Guido's exchange. - A function in the warn module is better than one in the sys module. "from warnings import warn" is good enough to not warrant a built-in. I get the sense that the PEP description is behind Guido's currently implementation here. - When PyErr_Warn() returns 1, does that mean a warning has been transmuted into an exception, or some other exception occurred during the setting of the warning? (I think I know, but the PEP could be clearer here). - It would be nice if lineno can be a range specification. Other matches are based on regexps -- think of this as a line number regexp. - Why not do setupwarnings() in site.py? - Regexp matching on messages should be case insensitive. - The second argument to sys.warn() or PyErr_Warn() can be any class, right? If so, it's easy for me to have my own warning classes. What if I want to set up my own warnings filters? Maybe if `action' could be a callable as well as a string. Then in my IDE, I could set that to "mygui.popupWarningsDialog". -Barry
Yes. I've updated the PEP to match the (2nd) implementation.
I've clarified this now: it returns 1 in either case. You have to do exception handling in either case. I'm not telling why -- you don't need to know. The caller of PyErr_Warn() should not attempt to catch the exception -- if that's your intent, you shouldn't be calling PyErr_Warn(). And PyErr_Warn() is complicated enough that it has to allow raising an exception.
Too much complexity already.
- Why not do setupwarnings() in site.py?
See the PEP and the current implementation. The delayed-loading of the warnings module means that we have to save the -W options as sys.warnoptions. (This also makes them work when multiple interpreters are used -- they all get the -W options.)
- Regexp matching on messages should be case insensitive.
Good point! Done in my version of the code.
- The second argument to sys.warn() or PyErr_Warn() can be any class, right?
Almost. It must be derived from __builtin__.Warning.
No, for that purpose you would override warnings.showwarning(). --Guido van Rossum (home page: http://www.python.org/~guido/)
"GvR" == Guido van Rossum <guido@python.org> writes:
GvR> I've clarified this now: it returns 1 in either case. You GvR> have to do exception handling in either case. I'm not GvR> telling why -- you don't need to know. The caller of GvR> PyErr_Warn() should not attempt to catch the exception -- if GvR> that's your intent, you shouldn't be calling PyErr_Warn(). GvR> And PyErr_Warn() is complicated enough that it has to allow GvR> raising an exception. Makes sense. >> - It would be nice if lineno can be a range specification. >> Other matches are based on regexps -- think of this as a line >> number regexp. GvR> Too much complexity already. Okay, no biggie I think. >> - Why not do setupwarnings() in site.py? GvR> See the PEP and the current implementation. The GvR> delayed-loading of the warnings module means that we have to GvR> save the -W options as sys.warnoptions. (This also makes GvR> them work when multiple interpreters are used -- they all get GvR> the -W options.) Cool. >> - Regexp matching on messages should be case insensitive. GvR> Good point! Done in my version of the code. Cool. >> - The second argument to sys.warn() or PyErr_Warn() can be any >> class, right? GvR> Almost. It must be derived from __builtin__.Warning. __builtin__.Warning == exceptions.Warning, right? >> If so, it's easy for me to have my own warning classes. What >> if I want to set up my own warnings filters? Maybe if `action' >> could be a callable as well as a string. Then in my IDE, I >> could set that to "mygui.popupWarningsDialog". GvR> No, for that purpose you would override GvR> warnings.showwarning(). Cool. Looks good. -Barry
On Mon, Dec 11, 2000 at 11:53:37AM -0500, Guido van Rossum wrote:
Since you must do "from warnings import warn" before using the warnings, then I think it makes sense to put the Warning classes into the warnings module. (e.g. why increase the size of the builtins?) Cheers, -g -- Greg Stein, http://www.lyra.org/
I don't particularly care whether the Warning category classes are builtins, but I can't declare them in the warnings module. Typical use from C is: if (PyErr_Warn(PyExc_DeprecationWarning, "the strop module is deprecated")) return NULL; PyErr_Warn() imports the warnings module on its first call. But the value of PyExc_DeprecationWarning c.s. must be available *before* the first call, so they can't be imported from the warnings module! My first version imported warnings at the start of the program, but this almost doubled the start-up time, hence the design where the module is imported only when needed. The most convenient place to create the Warning category classes is in the _exceptions module; doing it the easiest way there means that they are automatically exported to __builtin__. This doesn't bother me enough to try and hide them. --Guido van Rossum (home page: http://www.python.org/~guido/)
On Mon, Dec 11, 2000 at 07:39:31PM -0500, Guido van Rossum wrote:
Do the following: pywarn.h or pyerrors.h: #define PyWARN_DEPRECATION "DeprecationWarning" ... if (PyErr_Warn(PyWARN_DEPRECATION, "the strop module is deprecated")) return NULL; The PyErr_Warn would then use the string to dynamically look up / bind to the correct value from the warnings module. By using the symbolic constant, you will catch typos in the C code (e.g. if people passed raw strings, then a typo won't be found until runtime; using symbols will catch the problem at compile time). The above strategy will allow for fully-delayed loading, and for all the warnings to be located in the "warnings" module. Cheers, -g -- Greg Stein, http://www.lyra.org/
Yeah, that would be a possibility, if it was deemed evil that the warnings appear in __builtin__. I don't see what's so evil about that. (There's also the problem that the C code must be able to create new warning categories, as long as they are derived from the Warning base class. Your approach above doesn't support this. I'm sure you can figure a way around that too. But I prefer to hear why you think it's needed first.) --Guido van Rossum (home page: http://www.python.org/~guido/)
On Mon, Dec 11, 2000 at 08:21:41PM -0500, Guido van Rossum wrote:
I'm just attempting to avoid dumping more names into __builtins__ is all. I don't believe there is anything intrinsically bad about putting more names in there, but avoiding the kitchen-sink metaphor for __builtins__ has got to be a Good Thing :-) Cheers, -g -- Greg Stein, http://www.lyra.org/
On Mon, Dec 11, 2000 at 11:02:29AM -0500, Barry A. Warsaw wrote:
+1 on this. I have a response to Guido's first posted PEP on my laptop, but due to a weekend in Germany wasn't able to post it before he updated the PEP. I guess I can delete the arguments for this, now ;) but lets just say I think 'sys' is being a bit overused, and the case of a function in sys and its data in another module is just plain silly.
How about returning 1 for 'warning turned into exception' and -1 for 'normal exception' ? It would be slightly more similar to other functions if '-1' meant 'exception', and it would be easy to put in an if statement -- and still allow C code to ignore the produced error, if it wanted to.
+0 on this... I'm not sure if such fine-grained control is really necessary. I liked the hint at 'per function' granularity, but I realise it's tricky to do right, what with naming issues and all that.
- Regexp matching on messages should be case insensitive.
How about being able to pass in compiled regexp objects as well as strings ? I haven't looked at the implementation at all, so I'm not sure how expensive it would be, but it might also be nice to have users (= programmers) pass in an object with its own 'match' method, so you can 'interactively' decide whether or not to raise an exception, popup a window, and what not. Sort of like letting 'action' be a callable, which I think is a good idea as well. -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
Why would you want this? The user clearly said that they wanted the exception! --Guido van Rossum (home page: http://www.python.org/~guido/)
On Mon, Dec 11, 2000 at 12:11:02PM -0500, Guido van Rossum wrote:
Why would you want this? The user clearly said that they wanted the exception!
The difference is that in one case, the user will see the original warning-turned-exception, and in the other she won't -- the warning will be lost. At best she'll see (by looking at the traceback) the code intended to give a warning (that might or might not have been turned into an exception) and failed. The warning code might decide to do something aditional to notify the user of the thing it intended to warn about, which ended up as a 'real' exception because of something else. It's no biggy, obviously, except that if you change your mind it will be hard to add it without breaking code. Even if you explicitly state the return value should be tested for boolean value, not greater-than-zero value. -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
Yes -- this is a standard convention in Python. if there's a bug in code that is used to raise or handle an exception, you get a traceback from that bug.
Nah. The warning code shouldn't worry about that. If there's a bug in PyErr_Warn(), that should get top priority until it's fixed. --Guido van Rossum (home page: http://www.python.org/~guido/)
I've checked in the essential parts of the warnings PEP, and closed the SF patch. I haven't checked in the examples in the patch -- it's too early for that. But I figured that it's easier to revise the code once it's checked in. I'm pretty confident that it works as advertised. Still missing is documentation: the warnings module, the new API functions, and the new command line option should all be documented. I'll work on that over the holidays. I consider the PEP done. --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum writes:
I've assigned a bug to you in case you forget. I've given it a "show-stopper" priority level, so I'll feel good ripping the code out if you don't get docs written in time. ;-) -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Digital Creations
participants (7)
-
barry＠digicool.com -
Fred L. Drake, Jr. -
Greg Stein -
Guido van Rossum -
Paul Prescod -
Paul Prescod -
Thomas Wouters