Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message
On 26 September 2013 15:42, Armin Rigo ar...@tunes.org wrote: Hi Nick, On Thu, Sep 26, 2013 at 6:59 AM, Nick Coghlan ncogh...@gmail.com wrote: I'm strongly in favour of Georg's one (Exception in __del__ caught and not propagated). Such a change is highly unlikely to happen, as it would require changing every location where we call PyErr_WriteUnraisable. Er, why? It seems to me it's a matter of changing these three lines in PyErr_WriteUnraisable(): - PyFile_WriteString(Exception ignored in: , f); + PyFile_WriteString(Exception in , f); PyFile_WriteObject(obj, f, 0); - PyFile_WriteString(\n, f); + PyFile_WriteString( caught and not propagated:\n, f); I don't see what makes this technically different from the other solution, Cannot propagate exception... Sure, that's doable, but it dumps the full repr of obj in the middle of the sentence. The thing that's not practical is the neat and tidy wording Georg proposed, because the thing passed as obj is actually an arbitrary Python object that may have a messy repr (like a bound method, which is what gets passed in the __del__ case), so there's definite merit in keeping that repr at the *end* of the header line. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message
Am 26.09.2013 08:22, schrieb Nick Coghlan: On 26 September 2013 15:42, Armin Rigo ar...@tunes.org wrote: Hi Nick, On Thu, Sep 26, 2013 at 6:59 AM, Nick Coghlan ncogh...@gmail.com wrote: I'm strongly in favour of Georg's one (Exception in __del__ caught and not propagated). Such a change is highly unlikely to happen, as it would require changing every location where we call PyErr_WriteUnraisable. Er, why? It seems to me it's a matter of changing these three lines in PyErr_WriteUnraisable(): - PyFile_WriteString(Exception ignored in: , f); + PyFile_WriteString(Exception in , f); PyFile_WriteObject(obj, f, 0); - PyFile_WriteString(\n, f); + PyFile_WriteString( caught and not propagated:\n, f); I don't see what makes this technically different from the other solution, Cannot propagate exception... Sure, that's doable, but it dumps the full repr of obj in the middle of the sentence. The thing that's not practical is the neat and tidy wording Georg proposed, because the thing passed as obj is actually an arbitrary Python object that may have a messy repr (like a bound method, which is what gets passed in the __del__ case), so there's definite merit in keeping that repr at the *end* of the header line. Then this should be fine, I guess? Exception caught and not propagated in: Georg ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message
On 26 September 2013 16:53, Georg Brandl g.bra...@gmx.net wrote: Sure, that's doable, but it dumps the full repr of obj in the middle of the sentence. The thing that's not practical is the neat and tidy wording Georg proposed, because the thing passed as obj is actually an arbitrary Python object that may have a messy repr (like a bound method, which is what gets passed in the __del__ case), so there's definite merit in keeping that repr at the *end* of the header line. Then this should be fine, I guess? Exception caught and not propagated in: Sure. I still prefer something like Could not propagate exception from: or Caller could not propagate exception from repr that better indicates we're suppressing it because it's infeasible to raise it rather than just because we feel like it, but any of them would offer a decent improvement over the status quo. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message
On 9/26/2013 3:17 AM, Nick Coghlan wrote: On 26 September 2013 16:53, Georg Brandl g.bra...@gmx.net wrote: Sure, that's doable, but it dumps the full repr of obj in the middle of the sentence. The thing that's not practical is the neat and tidy wording Georg proposed, because the thing passed as obj is actually an arbitrary Python object that may have a messy repr (like a bound method, which is what gets passed in the __del__ case), so there's definite merit in keeping that repr at the *end* of the header line. Then this should be fine, I guess? Exception caught and not propagated in: Sure. I still prefer something like Could not propagate exception from: or Caller could not propagate exception from repr that better indicates we're suppressing it because it's infeasible to raise it rather than just because we feel like it, but any of them would offer a decent improvement over the status quo. With the full traceback printed, with the line where the exception originated, I do not think that the representation of the object is needed. It was a substitute for the traceback. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message
Am 24.09.2013 00:11, schrieb Greg Ewing: Antoine Pitrou wrote: Yes, but I agree with Greg that unraisable is wrong. After all, it was raised, and it can even be caught by the programmer (inside __del__). How about something like Uncaught exception in __del__ method ignored? It explains fairly clearly what has happened, and also indicates what do do about it -- catch it in the __del__ method. Exception in __del__ caught and not propagated: Georg ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message
[ I've replied to two messages here: Georg's and Glenn's (supporting MRAB's). - Cameron ] On 25Sep2013 08:22, Georg Brandl g.bra...@gmx.net wrote: | Am 24.09.2013 00:11, schrieb Greg Ewing: | How about something like Uncaught exception in __del__ | method ignored? It explains fairly clearly what has | happened, and also indicates what do do about it -- | catch it in the __del__ method. | | Exception in __del__ caught and not propagated: | Georg On 24Sep2013 09:33, Glenn Linderman v+pyt...@g.nevcal.com wrote: | [MRAB]: | Why not just say something like Cannot propagate exception...; it's | simpler than Unpropagatable exception [...] | | First one I've heard that accurately and unambiguously and briefly | describes the issue. | +1 I'm strongly in favour of Georg's one (Exception in __del__ caught and not propagated). Why? It says simply and clearly what has happened. It denotes the relevant context (__del__) in which it happened. The reader can then decide to find out why that decision may have been made. Why not MRAB's? (Cannot propagate exception...) While better than Unpropagatable exception and unraisable and unreraisable, it has the same flaw that I think underlies Antoine's concerns: it suggests the reason there's an error printed instead of further propagation is a _property of the exception_. It doesn't say it outright, but as an outsider that is definitely what I would at first infer. So: a small +0.1 for Cannot propagate exception... And: a big +2 for Exception in __del__ caught and not propagated:. Cheers, -- Cameron Simpson c...@zip.com.au Let the bullet of your thought achieve the true and final path of its trajectory before it reaches the ear of the listener, lest it plow out the other side of his head. - Henry David Thoreau ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message
On 26/09/2013 00:05, Cameron Simpson wrote: [ I've replied to two messages here: Georg's and Glenn's (supporting MRAB's). - Cameron ] On 25Sep2013 08:22, Georg Brandl g.bra...@gmx.net wrote: | Am 24.09.2013 00:11, schrieb Greg Ewing: | How about something like Uncaught exception in __del__ | method ignored? It explains fairly clearly what has | happened, and also indicates what do do about it -- | catch it in the __del__ method. | | Exception in __del__ caught and not propagated: | Georg On 24Sep2013 09:33, Glenn Linderman v+pyt...@g.nevcal.com wrote: | [MRAB]: | Why not just say something like Cannot propagate exception...; it's | simpler than Unpropagatable exception [...] | | First one I've heard that accurately and unambiguously and briefly | describes the issue. | +1 I'm strongly in favour of Georg's one (Exception in __del__ caught and not propagated). Why? It says simply and clearly what has happened. It denotes the relevant context (__del__) in which it happened. The reader can then decide to find out why that decision may have been made. Why not MRAB's? (Cannot propagate exception...) While better than Unpropagatable exception and unraisable and unreraisable, it has the same flaw that I think underlies Antoine's concerns: it suggests the reason there's an error printed instead of further propagation is a _property of the exception_. It doesn't say it outright, but as an outsider that is definitely what I would at first infer. So: a small +0.1 for Cannot propagate exception... And: a big +2 for Exception in __del__ caught and not propagated:. Well, my suggestion was more about eliminating the adjective+noun form; it seemed it just wasn't possible to cram the desired meaning into a single word, so it was better not to try! ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message
On 9/25/2013 5:17 PM, MRAB wrote: On 26/09/2013 00:05, Cameron Simpson wrote: [ I've replied to two messages here: Georg's and Glenn's (supporting MRAB's). - Cameron ] On 25Sep2013 08:22, Georg Brandl g.bra...@gmx.net wrote: | Am 24.09.2013 00:11, schrieb Greg Ewing: | How about something like Uncaught exception in __del__ | method ignored? It explains fairly clearly what has | happened, and also indicates what do do about it -- | catch it in the __del__ method. | | Exception in __del__ caught and not propagated: | Georg On 24Sep2013 09:33, Glenn Linderman v+pyt...@g.nevcal.com wrote: | [MRAB]: | Why not just say something like Cannot propagate exception...; it's | simpler than Unpropagatable exception [...] | | First one I've heard that accurately and unambiguously and briefly | describes the issue. | +1 I'm strongly in favour of Georg's one (Exception in __del__ caught and not propagated). Why? It says simply and clearly what has happened. It denotes the relevant context (__del__) in which it happened. The reader can then decide to find out why that decision may have been made. Why not MRAB's? (Cannot propagate exception...) While better than Unpropagatable exception and unraisable and unreraisable, it has the same flaw that I think underlies Antoine's concerns: it suggests the reason there's an error printed instead of further propagation is a _property of the exception_. It doesn't say it outright, but as an outsider that is definitely what I would at first infer. So: a small +0.1 for Cannot propagate exception... And: a big +2 for Exception in __del__ caught and not propagated:. Well, my suggestion was more about eliminating the adjective+noun form; it seemed it just wasn't possible to cram the desired meaning into a single word, so it was better not to try! Georg hadn't suggested his yet when I approved MRAB's, but your reasoning is sound, Cameron, unless there is some reason that the message can't or shouldn't be as long as what Georg suggested. In between in length and clarity might be: __del__ cannot propagate exception All of these are less confusing that the adj+noun form, that MRAB was the first to get away from. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message
On 26 September 2013 09:05, Cameron Simpson c...@zip.com.au wrote: On 24Sep2013 09:33, Glenn Linderman v+pyt...@g.nevcal.com wrote: | [MRAB]: | Why not just say something like Cannot propagate exception...; it's | simpler than Unpropagatable exception [...] | | First one I've heard that accurately and unambiguously and briefly | describes the issue. | +1 I'm strongly in favour of Georg's one (Exception in __del__ caught and not propagated). Why? It says simply and clearly what has happened. It denotes the relevant context (__del__) in which it happened. The reader can then decide to find out why that decision may have been made. Such a change is highly unlikely to happen, as it would require changing every location where we call PyErr_WriteUnraisable. Why not MRAB's? (Cannot propagate exception...) While better than Unpropagatable exception and unraisable and unreraisable, it has the same flaw that I think underlies Antoine's concerns: it suggests the reason there's an error printed instead of further propagation is a _property of the exception_. It doesn't say it outright, but as an outsider that is definitely what I would at first infer. It's substantially better than the status quo, though, and it shouldn't require any changes outside PyErr_WriteUnraisable. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message
Hi Nick, On Thu, Sep 26, 2013 at 6:59 AM, Nick Coghlan ncogh...@gmail.com wrote: I'm strongly in favour of Georg's one (Exception in __del__ caught and not propagated). Such a change is highly unlikely to happen, as it would require changing every location where we call PyErr_WriteUnraisable. Er, why? It seems to me it's a matter of changing these three lines in PyErr_WriteUnraisable(): - PyFile_WriteString(Exception ignored in: , f); + PyFile_WriteString(Exception in , f); PyFile_WriteObject(obj, f, 0); - PyFile_WriteString(\n, f); + PyFile_WriteString( caught and not propagated:\n, f); I don't see what makes this technically different from the other solution, Cannot propagate exception... A bientôt, Armin. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message
On 24 September 2013 08:29, Antoine Pitrou solip...@pitrou.net wrote: On Mon, 23 Sep 2013 14:38:48 -0700 Ethan Furman et...@stoneleaf.us wrote: But that's because you already know what it's supposed to convey. The average user doesn't, and only sees unraisable. All the more reason to have text in the error message that is easily searchable. Then I propose CA6yuaYV6dygPfJRxUrhtg. It should be easily searchable ;-) Seriously, easily searchable is a rather weak criterion for an error message. It should be easily understandable and non-misleading first. You are setting the bar unreasonably high for an error message that has to convey a complex concept in as few words as possible. There is *NO* wording that can concisely express the concepts involved without resorting to jargon, because the concepts behind it are *complex and unintuitive*. The current wording is flat out wrong, because the exception isn't being ignored, it's being printed to stderr. If it was genuinely being ignored, people wouldn't complain about it. Jargon that can be easily looked up with a search engine is greatly superior to a message that is simply wrong, as the former provides a gateway to understanding, just like coming across a word you don't understand when reading a novel. Preferring the status quo because you're holding out a forlorn hope for a concise wording that explains: - there are places where exceptions may occur but the interpreter can't reraise them - this is one of those cases, so we're printing it to stderr instead *without users needing to do any research*. A verbose wording is no good either, as that degenerates into a wall of text that people will *still* have to extract pieces from to plug into a search engine to figure out what they mean. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message
On 24 September 2013 10:50, Stephen J. Turnbull step...@xemacs.org wrote: MRAB writes: The word doesn't literally mean the exception itself was unraisable. It means it was raised, we caught it and we're writing it to stderr because we *can't raise it again*. Ah, you mean unreraisable. :-) +1 Ugly as sin, but satisfies all other criteria (except for Antoine's easily understandable which simply can't be satisfied). If you're drawing a distinction between the first time an exception hits the eval loop and the second and subsequent times, then neither Unraisable nor Unreraisable is 100% correct. I just think it's a meaningless distinction, which is why I favour Unraisable - at the point in time where that message is displayed, that exception cannot be raised any further, whether it was created directly from C or was received from an underlying call back into Python code.. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message
On 24 September 2013 17:25, Nick Coghlan ncogh...@gmail.com wrote: Preferring the status quo because you're holding out a forlorn hope for a concise wording that explains: - there are places where exceptions may occur but the interpreter can't reraise them - this is one of those cases, so we're printing it to stderr instead *without users needing to do any research*. Oops, reworded the second part of that sentence without fixing the first part. It should have said: == It doesn't make sense to prefer the status quo because you're holding out a forlorn hope for a concise wording that explains: - there are places where exceptions may occur but the interpreter can't reraise them - this is one of those cases, so we're printing it to stderr instead *without users needing to do any research*. == Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message
On Tue, 24 Sep 2013 17:25:10 +1000 Nick Coghlan ncogh...@gmail.com wrote: You are setting the bar unreasonably high for an error message that has to convey a complex concept in as few words as possible. There is *NO* wording that can concisely express the concepts involved without resorting to jargon, because the concepts behind it are *complex and unintuitive*. The current wording is flat out wrong, because the exception isn't being ignored, it's being printed to stderr. If it was genuinely being ignored, people wouldn't complain about it. Jargon that can be easily looked up with a search engine is greatly superior to a message that is simply wrong, as the former provides a gateway to understanding, just like coming across a word you don't understand when reading a novel. Unraisable is not a word I don't understand, it's a word that I understand and which conveys the wrong meaning. If you want something that people won't understand, you can use something like asynchronous exception. Preferring the status quo because you're holding out a forlorn hope for a concise wording that explains: I've proposed other options. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message
On 24 September 2013 17:34, Antoine Pitrou solip...@pitrou.net wrote: On Tue, 24 Sep 2013 17:25:10 +1000 Nick Coghlan ncogh...@gmail.com wrote: You are setting the bar unreasonably high for an error message that has to convey a complex concept in as few words as possible. There is *NO* wording that can concisely express the concepts involved without resorting to jargon, because the concepts behind it are *complex and unintuitive*. The current wording is flat out wrong, because the exception isn't being ignored, it's being printed to stderr. If it was genuinely being ignored, people wouldn't complain about it. Jargon that can be easily looked up with a search engine is greatly superior to a message that is simply wrong, as the former provides a gateway to understanding, just like coming across a word you don't understand when reading a novel. Unraisable is not a word I don't understand, it's a word that I understand and which conveys the wrong meaning. How is it wrong? At the point where the interpreter says This exception is now unraisable, what, precisely, is it saying that is wrong? It isn't saying this has never been raised. It is saying, where it is currently being processed, this exception cannot be raised. If you want something that people won't understand, you can use something like asynchronous exception. Asynchronous exception is *even more* wrong, because that's the terminology used for an exception injected into the current thread by a different thread. Preferring the status quo because you're holding out a forlorn hope for a concise wording that explains: I've proposed other options. Automatically caught says nothing about why the exception is being printed to stderr instead of propagating normally. Exceptions are automatically caught by any matching except clause all the time, but most of those don't result in errors printed to stderr. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message
On Tue, 24 Sep 2013 18:06:15 +1000 Nick Coghlan ncogh...@gmail.com wrote: How is it wrong? At the point where the interpreter says This exception is now unraisable, what, precisely, is it saying that is wrong? It isn't saying this has never been raised. It is saying, where it is currently being processed, this exception cannot be raised. Well, it is saying it. If it's conceptually unraisable, it can't be raised. I know your point is that it is only unraisable *now*, but that's not the intuitive interpretation. Preferring the status quo because you're holding out a forlorn hope for a concise wording that explains: I've proposed other options. Automatically caught says nothing about why the exception is being printed to stderr instead of propagating normally. Exceptions are automatically caught by any matching except clause all the time, but most of those don't result in errors printed to stderr. I would say they are manually caught by except clauses (user code == manual intervention), and automatically caught when silenced or unraised by the interpreter. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message
On 24/09/2013 09:06, Nick Coghlan wrote: On 24 September 2013 17:34, Antoine Pitrou solip...@pitrou.net wrote: On Tue, 24 Sep 2013 17:25:10 +1000 Nick Coghlan ncogh...@gmail.com wrote: You are setting the bar unreasonably high for an error message that has to convey a complex concept in as few words as possible. There is *NO* wording that can concisely express the concepts involved without resorting to jargon, because the concepts behind it are *complex and unintuitive*. The current wording is flat out wrong, because the exception isn't being ignored, it's being printed to stderr. If it was genuinely being ignored, people wouldn't complain about it. Jargon that can be easily looked up with a search engine is greatly superior to a message that is simply wrong, as the former provides a gateway to understanding, just like coming across a word you don't understand when reading a novel. Unraisable is not a word I don't understand, it's a word that I understand and which conveys the wrong meaning. How is it wrong? At the point where the interpreter says This exception is now unraisable, what, precisely, is it saying that is wrong? It isn't saying this has never been raised. It is saying, where it is currently being processed, this exception cannot be raised. If you want something that people won't understand, you can use something like asynchronous exception. Asynchronous exception is *even more* wrong, because that's the terminology used for an exception injected into the current thread by a different thread. Preferring the status quo because you're holding out a forlorn hope for a concise wording that explains: I've proposed other options. Automatically caught says nothing about why the exception is being printed to stderr instead of propagating normally. Exceptions are automatically caught by any matching except clause all the time, but most of those don't result in errors printed to stderr. Why not just say something like Cannot propagate exception...; it's simpler than Unpropagatable exception ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message
On 24 Sep 2013 20:06, MRAB pyt...@mrabarnett.plus.com wrote: On 24/09/2013 09:06, Nick Coghlan wrote: On 24 September 2013 17:34, Antoine Pitrou solip...@pitrou.net wrote: On Tue, 24 Sep 2013 17:25:10 +1000 Nick Coghlan ncogh...@gmail.com wrote: You are setting the bar unreasonably high for an error message that has to convey a complex concept in as few words as possible. There is *NO* wording that can concisely express the concepts involved without resorting to jargon, because the concepts behind it are *complex and unintuitive*. The current wording is flat out wrong, because the exception isn't being ignored, it's being printed to stderr. If it was genuinely being ignored, people wouldn't complain about it. Jargon that can be easily looked up with a search engine is greatly superior to a message that is simply wrong, as the former provides a gateway to understanding, just like coming across a word you don't understand when reading a novel. Unraisable is not a word I don't understand, it's a word that I understand and which conveys the wrong meaning. How is it wrong? At the point where the interpreter says This exception is now unraisable, what, precisely, is it saying that is wrong? It isn't saying this has never been raised. It is saying, where it is currently being processed, this exception cannot be raised. If you want something that people won't understand, you can use something like asynchronous exception. Asynchronous exception is *even more* wrong, because that's the terminology used for an exception injected into the current thread by a different thread. Preferring the status quo because you're holding out a forlorn hope for a concise wording that explains: I've proposed other options. Automatically caught says nothing about why the exception is being printed to stderr instead of propagating normally. Exceptions are automatically caught by any matching except clause all the time, but most of those don't result in errors printed to stderr. Why not just say something like Cannot propagate exception...; it's simpler than Unpropagatable exception That would definitely be an improvement on the status quo and avoids Antoine's concern about an adjective being interpreted as an inherent property of the exception rather than the circumstances where the exception was encountered. Cheers, Nick. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message
24.09.2013 10:16, Antoine Pitrou wrote: On Tue, 24 Sep 2013 18:06:15 +1000 Nick Coghlan ncogh...@gmail.com wrote: How is it wrong? At the point where the interpreter says This exception is now unraisable, what, precisely, is it saying that is wrong? It isn't saying this has never been raised. It is saying, where it is currently being processed, this exception cannot be raised. Well, it is saying it. If it's conceptually unraisable, it can't be raised. I know your point is that it is only unraisable *now*, but that's not the intuitive interpretation. And what about: Exception not propagated from bound method C.__del__ of __main__.C object at 0x7f98b8b61538 ... Or: Exception that cannot be propagated from bound method C.__del__ of __main__.C object at 0x7f98b8b61538 ... Cheers. *j ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message
On 9/24/2013 5:51 AM, Nick Coghlan wrote: Why not just say something like Cannot propagate exception...; it's simpler than Unpropagatable exception That would definitely be an improvement on the status quo and avoids Antoine's concern about an adjective being interpreted as an inherent property of the exception rather than the circumstances where the exception was encountered. First one I've heard that accurately and unambiguously and briefly describes the issue. +1 ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message
Guido van Rossum wrote: Somehow unraisable sounds too technical, It's not even really accurate. It's been raised, it just can't be propagated any further. But unpropagatable exception would be a bit of a mouthful. -- Greg ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message
On 23 September 2013 16:11, Greg Ewing greg.ew...@canterbury.ac.nz wrote: Guido van Rossum wrote: Somehow unraisable sounds too technical, It's not even really accurate. It's been raised, it just can't be propagated any further. But unpropagatable exception would be a bit of a mouthful. I felt I needed a reminder of the context where this string gets printed, so I created this toy example: class C: ... def __del__(self): ... raise RuntimeError(Going away now) ... x = C() del x Exception ignored in: bound method C.__del__ of __main__.C object at 0x7f98b8b61538 Traceback (most recent call last): File stdin, line 3, in __del__ RuntimeError: Going away now Here's what I suggest changing that error to: del x Unraisable exception suppressed when calling bound method C.__del__ of __main__.C object at 0x7f98b8b61538 Traceback (most recent call last): File stdin, line 3, in __del__ RuntimeError: Going away now First and foremost, Unraisable exception suppressed should be quite search engine friendly. The only current hits for that are on archived versions of this thread, whereas the existing Exception ignored sends you down a rabbit hole of Stack Overflow answers related to broken pipe handling. If we create a new FAQ entry for What does 'Exception ignored' or 'Unraisable exception suppressed' mean? when making the change for 3.4, then that will definitely help 3.4 users and may eventually help users of other versions as well :) Secondly, it concisely explains exactly what is going on, so developers that look it up once should be able to remember the meaning in the future: - the given exception was suppressed (*what* happened) - it was suppressed because Python couldn't raise it any further (*why* it happened) I think it's OK for the terms to be a little technical and arcane because problems relating to broken finalizers and failures during interpreter startup and shutdown *are* a little arcane. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message
Le Mon, 23 Sep 2013 18:17:51 +1000, Nick Coghlan ncogh...@gmail.com a écrit : Here's what I suggest changing that error to: del x Unraisable exception suppressed when calling bound method C.__del__ of __main__.C object at 0x7f98b8b61538 Traceback (most recent call last): File stdin, line 3, in __del__ RuntimeError: Going away now Why not simply Exception automatically caught in bound method C.__del__ [...] ? Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message
On 23 September 2013 18:45, Antoine Pitrou solip...@pitrou.net wrote: Le Mon, 23 Sep 2013 18:17:51 +1000, Nick Coghlan ncogh...@gmail.com a écrit : Here's what I suggest changing that error to: del x Unraisable exception suppressed when calling bound method C.__del__ of __main__.C object at 0x7f98b8b61538 Traceback (most recent call last): File stdin, line 3, in __del__ RuntimeError: Going away now Why not simply Exception automatically caught in bound method C.__del__ [...] ? It only answers the what (i.e. the exception was automatically caught), without addressing the why (i.e. because there wasn't anything else useful the interpreter could do with it) Suppressed also says more than caught does, since caught and reraised the exception makes sense, while suppressed and reraised the exception contradicts itself. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message
On Mon, 23 Sep 2013 18:51:04 +1000 Nick Coghlan ncogh...@gmail.com wrote: On 23 September 2013 18:45, Antoine Pitrou solip...@pitrou.net wrote: Le Mon, 23 Sep 2013 18:17:51 +1000, Nick Coghlan ncogh...@gmail.com a écrit : Here's what I suggest changing that error to: del x Unraisable exception suppressed when calling bound method C.__del__ of __main__.C object at 0x7f98b8b61538 Traceback (most recent call last): File stdin, line 3, in __del__ RuntimeError: Going away now Why not simply Exception automatically caught in bound method C.__del__ [...] ? It only answers the what (i.e. the exception was automatically caught), without addressing the why (i.e. because there wasn't anything else useful the interpreter could do with it) Yes, but I agree with Greg that unraisable is wrong. After all, it was raised, and it can even be caught by the programmer (inside __del__). Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message
On 9/23/2013 12:23 PM, R. David Murray wrote:
On Mon, 23 Sep 2013 17:22:45 +0200, Antoine Pitrou solip...@pitrou.net wrote:
On Mon, 23 Sep 2013 18:51:04 +1000
Nick Coghlan ncogh...@gmail.com wrote:
On 23 September 2013 18:45, Antoine Pitrou solip...@pitrou.net wrote:
Le Mon, 23 Sep 2013 18:17:51 +1000,
Nick Coghlan ncogh...@gmail.com a écrit :
Here's what I suggest changing that error to:
del x
Unraisable exception suppressed when calling bound method C.__del__
of __main__.C object at 0x7f98b8b61538
Traceback (most recent call last):
File stdin, line 3, in __del__
RuntimeError: Going away now
Why not simply Exception automatically caught in bound method
C.__del__ [...] ?
It only answers the what (i.e. the exception was automatically
caught), without addressing the why (i.e. because there wasn't
anything else useful the interpreter could do with it)
Yes, but I agree with Greg that unraisable is wrong. After all, it
was raised, and it can even be caught by the programmer (inside
__del__).
Would it work to say Asynchronous exception suppressed...? It's
not-entirely-precise,
As in the example above ('del x').
but it's less imprecise than unraisable.
How 'troublesome'? That is always accurate, as proven by this thread.
We really need an Understanding Exceptions HOWTO, and I expect we will
get one. So I agree with Nick that something easily searched would be good.
--
Terry Jan Reedy
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message
On 24 Sep 2013 01:24, Antoine Pitrou solip...@pitrou.net wrote: On Mon, 23 Sep 2013 18:51:04 +1000 Nick Coghlan ncogh...@gmail.com wrote: On 23 September 2013 18:45, Antoine Pitrou solip...@pitrou.net wrote: Le Mon, 23 Sep 2013 18:17:51 +1000, Nick Coghlan ncogh...@gmail.com a écrit : Here's what I suggest changing that error to: del x Unraisable exception suppressed when calling bound method C.__del__ of __main__.C object at 0x7f98b8b61538 Traceback (most recent call last): File stdin, line 3, in __del__ RuntimeError: Going away now Why not simply Exception automatically caught in bound method C.__del__ [...] ? It only answers the what (i.e. the exception was automatically caught), without addressing the why (i.e. because there wasn't anything else useful the interpreter could do with it) Yes, but I agree with Greg that unraisable is wrong. After all, it was raised, and it can even be caught by the programmer (inside __del__). The word doesn't literally mean the exception itself was unraisable. It means it was raised, we caught it and we're writing it to stderr because we *can't raise it again*. The relevant C API function is just called PyErr_WriteUnraisable, not PyErr_WriteUnraisableButThatIsTechnicallyWrongSinceItWasAlreadyRaisedAndWeJustCaughtItAndAreNowReportingItToStdErr. Cheers, Nick. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message
On Tue, 24 Sep 2013 07:19:14 +1000 Nick Coghlan ncogh...@gmail.com wrote: On 24 Sep 2013 01:24, Antoine Pitrou solip...@pitrou.net wrote: On Mon, 23 Sep 2013 18:51:04 +1000 Nick Coghlan ncogh...@gmail.com wrote: On 23 September 2013 18:45, Antoine Pitrou solip...@pitrou.net wrote: Le Mon, 23 Sep 2013 18:17:51 +1000, Nick Coghlan ncogh...@gmail.com a écrit : Here's what I suggest changing that error to: del x Unraisable exception suppressed when calling bound method C.__del__ of __main__.C object at 0x7f98b8b61538 Traceback (most recent call last): File stdin, line 3, in __del__ RuntimeError: Going away now Why not simply Exception automatically caught in bound method C.__del__ [...] ? It only answers the what (i.e. the exception was automatically caught), without addressing the why (i.e. because there wasn't anything else useful the interpreter could do with it) Yes, but I agree with Greg that unraisable is wrong. After all, it was raised, and it can even be caught by the programmer (inside __del__). The word doesn't literally mean the exception itself was unraisable. It means it was raised, we caught it and we're writing it to stderr because we *can't raise it again*. But that's because you already know what it's supposed to convey. The average user doesn't, and only sees unraisable. The relevant C API function is just called PyErr_WriteUnraisable, not PyErr_WriteUnraisableButThatIsTechnicallyWrongSinceItWasAlreadyRaisedAndWeJustCaughtItAndAreNowReportingItToStdErr. PyErr_WriteUnraisable is right at the point where it used: I can't raise that exception at this point, therefore I call PyErr_WriteUnraisable. However, from the point of view of the user reading the traceback, the exception *was* raised. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message
On 09/23/2013 02:19 PM, Nick Coghlan wrote: The relevant C API function is just called PyErr_WriteUnraisable, not PyErr_WriteUnraisableButThatIsTechnicallyWrongSinceItWasAlreadyRaisedAndWeJustCaughtItAndAreNowReportingItToStdErr. Wow. How many legs does that HumptyCamel have, anyway? ;) -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message
Antoine Pitrou wrote: Yes, but I agree with Greg that unraisable is wrong. After all, it was raised, and it can even be caught by the programmer (inside __del__). How about something like Uncaught exception in __del__ method ignored? It explains fairly clearly what has happened, and also indicates what do do about it -- catch it in the __del__ method. -- Greg ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message
On 09/23/2013 02:35 PM, Antoine Pitrou wrote: On Tue, 24 Sep 2013 07:19:14 +1000 Nick Coghlan ncogh...@gmail.com wrote: On 24 Sep 2013 01:24, Antoine Pitrou solip...@pitrou.net wrote: On Mon, 23 Sep 2013 18:51:04 +1000 Nick Coghlan ncogh...@gmail.com wrote: On 23 September 2013 18:45, Antoine Pitrou solip...@pitrou.net wrote: Le Mon, 23 Sep 2013 18:17:51 +1000, Nick Coghlan ncogh...@gmail.com a écrit : Here's what I suggest changing that error to: del x Unraisable exception suppressed when calling bound method C.__del__ of __main__.C object at 0x7f98b8b61538 Traceback (most recent call last): File stdin, line 3, in __del__ RuntimeError: Going away now Why not simply Exception automatically caught in bound method C.__del__ [...] ? It only answers the what (i.e. the exception was automatically caught), without addressing the why (i.e. because there wasn't anything else useful the interpreter could do with it) Yes, but I agree with Greg that unraisable is wrong. After all, it was raised, and it can even be caught by the programmer (inside __del__). The word doesn't literally mean the exception itself was unraisable. It means it was raised, we caught it and we're writing it to stderr because we *can't raise it again*. But that's because you already know what it's supposed to convey. The average user doesn't, and only sees unraisable. All the more reason to have text in the error message that is easily searchable. -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message
On Mon, 23 Sep 2013 14:38:48 -0700 Ethan Furman et...@stoneleaf.us wrote: But that's because you already know what it's supposed to convey. The average user doesn't, and only sees unraisable. All the more reason to have text in the error message that is easily searchable. Then I propose CA6yuaYV6dygPfJRxUrhtg. It should be easily searchable ;-) Seriously, easily searchable is a rather weak criterion for an error message. It should be easily understandable and non-misleading first. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message
On 23/09/2013 22:19, Nick Coghlan wrote: On 24 Sep 2013 01:24, Antoine Pitrou solip...@pitrou.net mailto:solip...@pitrou.net wrote: On Mon, 23 Sep 2013 18:51:04 +1000 Nick Coghlan ncogh...@gmail.com mailto:ncogh...@gmail.com wrote: On 23 September 2013 18:45, Antoine Pitrou solip...@pitrou.net mailto:solip...@pitrou.net wrote: Le Mon, 23 Sep 2013 18:17:51 +1000, Nick Coghlan ncogh...@gmail.com mailto:ncogh...@gmail.com a écrit : Here's what I suggest changing that error to: del x Unraisable exception suppressed when calling bound method C.__del__ of __main__.C object at 0x7f98b8b61538 Traceback (most recent call last): File stdin, line 3, in __del__ RuntimeError: Going away now Why not simply Exception automatically caught in bound method C.__del__ [...] ? It only answers the what (i.e. the exception was automatically caught), without addressing the why (i.e. because there wasn't anything else useful the interpreter could do with it) Yes, but I agree with Greg that unraisable is wrong. After all, it was raised, and it can even be caught by the programmer (inside __del__). The word doesn't literally mean the exception itself was unraisable. It means it was raised, we caught it and we're writing it to stderr because we *can't raise it again*. Ah, you mean unreraisable. :-) The relevant C API function is just called PyErr_WriteUnraisable, not PyErr_WriteUnraisableButThatIsTechnicallyWrongSinceItWasAlreadyRaisedAndWeJustCaughtItAndAreNowReportingItToStdErr. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message
MRAB writes: The word doesn't literally mean the exception itself was unraisable. It means it was raised, we caught it and we're writing it to stderr because we *can't raise it again*. Ah, you mean unreraisable. :-) +1 Ugly as sin, but satisfies all other criteria (except for Antoine's easily understandable which simply can't be satisfied). ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message
On Sat, 21 Sep 2013 19:55:05 -0400 Terry Reedy tjre...@udel.edu wrote: In the general case it represents a bug in the code that should be fixed. Most such errors arise from the vagaries of module finalization (such as your issue 19021), Lets call that a buglet ;-). Not really harmful, but annoying. It's not a buglet. A buggy __del__ method is as much a bug as any other buggy method. __del__ issues can lead to resources not being properly finalized and released to the system. Accepting that even such buglets 'should' be fixed in the stdllib, so that the message does not appear, is there any reason *not* to make it a RuntimeWarning so that users who care about clean output can filter it out while waiting for us to fix it? Yes, the reason is that these are real exceptions, not warnings. The reason the exceptions are not propagated is that they can occur at any point (finalization is pretty much asynchronous, it can occur from unrelated places), so propagating them to whatever code happens to execute at the time would be a huge instability factor. Making them warnings means they could be silenced depending on the current warning settings. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message
On 09/22/2013 10:19 AM, Antoine Pitrou wrote: On Sat, 21 Sep 2013 19:55:05 -0400 Terry Reedy tjre...@udel.edu wrote: In the general case it represents a bug in the code that should be fixed. Most such errors arise from the vagaries of module finalization (such as your issue 19021), Lets call that a buglet ;-). Not really harmful, but annoying. It's not a buglet. A buggy __del__ method is as much a bug as any other buggy method. __del__ issues can lead to resources not being properly finalized and released to the system. Accepting that even such buglets 'should' be fixed in the stdllib, so that the message does not appear, is there any reason *not* to make it a RuntimeWarning so that users who care about clean output can filter it out while waiting for us to fix it? Yes, the reason is that these are real exceptions, not warnings. The reason the exceptions are not propagated is that they can occur at any point (finalization is pretty much asynchronous, it can occur from unrelated places), so propagating them to whatever code happens to execute at the time would be a huge instability factor. Making them warnings means they could be silenced depending on the current warning settings. Which is not too bad, right? (Assuming it's not silent by default.) However, I'm not sure invoking the whole complicated warning filtering and emitting code is what we want to do in a destructor... Georg ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message
On Sun, 22 Sep 2013 10:48:33 +0200 Georg Brandl g.bra...@gmx.net wrote: On 09/22/2013 10:19 AM, Antoine Pitrou wrote: On Sat, 21 Sep 2013 19:55:05 -0400 Terry Reedy tjre...@udel.edu wrote: In the general case it represents a bug in the code that should be fixed. Most such errors arise from the vagaries of module finalization (such as your issue 19021), Lets call that a buglet ;-). Not really harmful, but annoying. It's not a buglet. A buggy __del__ method is as much a bug as any other buggy method. __del__ issues can lead to resources not being properly finalized and released to the system. Accepting that even such buglets 'should' be fixed in the stdllib, so that the message does not appear, is there any reason *not* to make it a RuntimeWarning so that users who care about clean output can filter it out while waiting for us to fix it? Yes, the reason is that these are real exceptions, not warnings. The reason the exceptions are not propagated is that they can occur at any point (finalization is pretty much asynchronous, it can occur from unrelated places), so propagating them to whatever code happens to execute at the time would be a huge instability factor. Making them warnings means they could be silenced depending on the current warning settings. Which is not too bad, right? (Assuming it's not silent by default.) The default is to print a given warning message only once, which isn't the normal semantics of exceptions. However, I'm not sure invoking the whole complicated warning filtering and emitting code is what we want to do in a destructor... Good point, too :-) Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message
On 9/21/2013 10:30 PM, Guido van Rossum wrote: Exceptions in __del__ point to bugs (sometimes in the stdlib) that should be fixed, period. The only reason they do not result in exceptions that are properly bubbled up and catchable is because __del__ is called from a DECREF macro which has no return value. That is clear enough. What fooled me is the word 'ignored', in both the doc and message. How about 'skipped' (for technical reasons)? Also, IMO writing to stderr is fair game -- reporting errors is what it is for. So developers who really want to control all screen output should redirect or capture it somehow. As to making them warnings, I don't know that the warnings machinery is easily adaptable for this purpose. Warnings can be suppressed but they can also be turned into full exceptions; the latter doesn't really apply here (see previous paragraph). But I would not object if someone found a way to do this, though I'd prefer the default behavior to remain what it is in 3.4 (print a full traceback). Antoine and Georg think it a dubious idea, so I will not pursue it. Developers who encounter messages from the stdlib can report and wait for a fix. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message
On Sun, Sep 22, 2013 at 10:35 AM, Terry Reedy tjre...@udel.edu wrote: On 9/21/2013 10:30 PM, Guido van Rossum wrote: Exceptions in __del__ point to bugs (sometimes in the stdlib) that should be fixed, period. The only reason they do not result in exceptions that are properly bubbled up and catchable is because __del__ is called from a DECREF macro which has no return value. That is clear enough. What fooled me is the word 'ignored', in both the doc and message. How about 'skipped' (for technical reasons)? That's a good point, although I'm not sure 'skipped' is better. Maybe use a more neutral verb like 'occurred'? -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message
On 9/22/2013 2:41 PM, Guido van Rossum wrote: On Sun, Sep 22, 2013 at 10:35 AM, Terry Reedy tjre...@udel.edu mailto:tjre...@udel.edu wrote: On 9/21/2013 10:30 PM, Guido van Rossum wrote: Exceptions in __del__ point to bugs (sometimes in the stdlib) that should be fixed, period. The only reason they do not result in exceptions that are properly bubbled up and catchable is because __del__ is called from a DECREF macro which has no return value. That is clear enough. What fooled me is the word 'ignored', in both the doc and message. How about 'skipped' (for technical reasons)? That's a good point, although I'm not sure 'skipped' is better. Only slightly ;-). The problem with both words is that they try to say two things. What happened, and what Python did about it. Maybe use a more neutral verb like 'occurred'? Exception occurred in ... is even better at say what happened. I think we should then add an explict statement as to what Python did, and hint at what the user should do, something like Although caught internally, it still indicates a problem. Otherwise, when no other output follows, as in ... del c Exception ocurred in: bound method C.__del__ ... Traceback (most recent call last): File pyshell#0, line 2, in __del__ AttributeError: It may not be completely obvious to a non-expert that the traceback is not a 'real' traceback from an exception that was allowed to propagate, and that it did not stop execution and cannot be caught. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message
On 23 Sep 2013 06:38, Terry Reedy tjre...@udel.edu wrote: On 9/22/2013 2:41 PM, Guido van Rossum wrote: On Sun, Sep 22, 2013 at 10:35 AM, Terry Reedy tjre...@udel.edu mailto:tjre...@udel.edu wrote: On 9/21/2013 10:30 PM, Guido van Rossum wrote: Exceptions in __del__ point to bugs (sometimes in the stdlib) that should be fixed, period. The only reason they do not result in exceptions that are properly bubbled up and catchable is because __del__ is called from a DECREF macro which has no return value. That is clear enough. What fooled me is the word 'ignored', in both the doc and message. How about 'skipped' (for technical reasons)? That's a good point, although I'm not sure 'skipped' is better. Only slightly ;-). The problem with both words is that they try to say two things. What happened, and what Python did about it. Maybe use a more neutral verb like 'occurred'? Exception occurred in ... is even better at say what happened. I think we should then add an explict statement as to what Python did, and hint at what the user should do, something like Although caught internally, it still indicates a problem. Brevity is still a virtue. The relevant C API function is called PyErr_WriteUnraisable, so just starting the message as something like Unraisable exception suppressed in... might work. Cheers, Nick. Otherwise, when no other output follows, as in ... del c Exception ocurred in: bound method C.__del__ ... Traceback (most recent call last): File pyshell#0, line 2, in __del__ AttributeError: It may not be completely obvious to a non-expert that the traceback is not a 'real' traceback from an exception that was allowed to propagate, and that it did not stop execution and cannot be caught. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message
On Sunday, September 22, 2013, Nick Coghlan wrote: Brevity is still a virtue. The relevant C API function is called PyErr_WriteUnraisable, so just starting the message as something like Unraisable exception suppressed in... might work. Somehow unraisable sounds too technical, and suppressed is hardly right given that it is printed... Let's leave well enough alone. --Guido -- --Guido van Rossum (on iPad) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message
On 09/22/2013 08:24 PM, Nick Coghlan wrote: On 23 Sep 2013 06:38, Terry Reedy tjre...@udel.edu mailto:tjre...@udel.edu wrote: On 9/22/2013 2:41 PM, Guido van Rossum wrote: On Sun, Sep 22, 2013 at 10:35 AM, Terry Reedy tjre...@udel.edu mailto:tjre...@udel.edu mailto:tjre...@udel.edu mailto:tjre...@udel.edu wrote: On 9/21/2013 10:30 PM, Guido van Rossum wrote: Exceptions in __del__ point to bugs (sometimes in the stdlib) that should be fixed, period. The only reason they do not result in exceptions that are properly bubbled up and catchable is because __del__ is called from a DECREF macro which has no return value. That is clear enough. What fooled me is the word 'ignored', in both the doc and message. How about 'skipped' (for technical reasons)? That's a good point, although I'm not sure 'skipped' is better. Only slightly ;-). The problem with both words is that they try to say two things. What happened, and what Python did about it. Maybe use a more neutral verb like 'occurred'? Exception occurred in ... is even better at say what happened. I think we should then add an explict statement as to what Python did, and hint at what the user should do, something like Although caught internally, it still indicates a problem. Brevity is still a virtue. The relevant C API function is called PyErr_WriteUnraisable, so just starting the message as something like Unraisable exception suppressed in... might work. I like that! +1 -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message
On 9/22/2013 9:29 PM, Guido van Rossum wrote: On Sunday, September 22, 2013, Nick Coghlan wrote: Brevity is still a virtue. The relevant C API function is called PyErr_WriteUnraisable, so just starting the message as something like Unraisable exception suppressed in... might work. Somehow unraisable sounds too technical, and suppressed is hardly right given that it is printed... Let's leave well enough alone. printable-only exception in... ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message
On Sat, 21 Sep 2013 17:16:41 -0400, Terry Reedy tjre...@udel.edu wrote: When an AttributeError is raised in a __del__ method, it is caught and ignored, except that it is not completely ignored but is replaced by a warning message sent to stderr. Example: class C(): def __del__(self): raise AttributeError c=C() del c Exception AttributeError: AttributeError() in bound method C.__del__ of __main__.C object at 0x0351A198 ignored This is a replacement for a traceback. In later Python versions, the full traceback is printed. In the general case it represents a bug in the code that should be fixed. Most such errors arise from the vagaries of module finalization (such as your issue 19021), but not all of them do: the rest represent real bugs in __del__ methods (which are executed asynchronously in the general case). So the question is, is the bug in the user code, or the stdlib code? From the issue, it sounds like it could be considered either (or most likely, both). --David ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message
On 9/21/2013 6:15 PM, R. David Murray wrote: On Sat, 21 Sep 2013 17:16:41 -0400, Terry Reedy tjre...@udel.edu wrote: When an AttributeError is raised in a __del__ method, it is caught and ignored, except that it is not completely ignored but is replaced by a warning message sent to stderr. Example: class C(): def __del__(self): raise AttributeError c=C() del c Exception AttributeError: AttributeError() in bound method C.__del__ of __main__.C object at 0x0351A198 ignored This is a replacement for a traceback. In later Python versions, the full traceback is printed. The above is 3.3.2. In 3.4.0a2, the traceback of the ignored exception is indeed printed. Exception ignored in: bound method C.__del__ of __main__.C object at 0x039946D8 Traceback (most recent call last): File pyshell#0, line 2, in __del__ AttributeError: In the general case it represents a bug in the code that should be fixed. Most such errors arise from the vagaries of module finalization (such as your issue 19021), Lets call that a buglet ;-). Not really harmful, but annoying. Accepting that even such buglets 'should' be fixed in the stdllib, so that the message does not appear, is there any reason *not* to make it a RuntimeWarning so that users who care about clean output can filter it out while waiting for us to fix it? This would be a separate issue from #12085. but not all of them do: the rest represent real bugs in __del__ methods (which are executed asynchronously in the general case). Which is why the message should be printed, so the developer can decide. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message
Exceptions in __del__ point to bugs (sometimes in the stdlib) that should be fixed, period. The only reason they do not result in exceptions that are properly bubbled up and catchable is because __del__ is called from a DECREF macro which has no return value. Also, IMO writing to stderr is fair game -- reporting errors is what it is for. As to making them warnings, I don't know that the warnings machinery is easily adaptable for this purpose. Warnings can be suppressed but they can also be turned into full exceptions; the latter doesn't really apply here (see previous paragraph). But I would not object if someone found a way to do this, though I'd prefer the default behavior to remain what it is in 3.4 (print a full traceback). On Sat, Sep 21, 2013 at 4:55 PM, Terry Reedy tjre...@udel.edu wrote: On 9/21/2013 6:15 PM, R. David Murray wrote: On Sat, 21 Sep 2013 17:16:41 -0400, Terry Reedy tjre...@udel.edu wrote: When an AttributeError is raised in a __del__ method, it is caught and ignored, except that it is not completely ignored but is replaced by a warning message sent to stderr. Example: class C(): def __del__(self): raise AttributeError c=C() del c Exception AttributeError: AttributeError() in bound method C.__del__ of __main__.C object at 0x0351A198 ignored This is a replacement for a traceback. In later Python versions, the full traceback is printed. The above is 3.3.2. In 3.4.0a2, the traceback of the ignored exception is indeed printed. Exception ignored in: bound method C.__del__ of __main__.C object at 0x039946D8 Traceback (most recent call last): File pyshell#0, line 2, in __del__ AttributeError: In the general case it represents a bug in the code that should be fixed. Most such errors arise from the vagaries of module finalization (such as your issue 19021), Lets call that a buglet ;-). Not really harmful, but annoying. Accepting that even such buglets 'should' be fixed in the stdllib, so that the message does not appear, is there any reason *not* to make it a RuntimeWarning so that users who care about clean output can filter it out while waiting for us to fix it? This would be a separate issue from #12085. but not all of them do: the rest represent real bugs in __del__ methods (which are executed asynchronously in the general case). Which is why the message should be printed, so the developer can decide. -- Terry Jan Reedy __**_ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/**mailman/listinfo/python-devhttps://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/**mailman/options/python-dev/** guido%40python.orghttps://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
