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
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
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
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
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
[ 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
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__
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
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
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
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
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
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
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
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*
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
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
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
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.
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
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
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
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,
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
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
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
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 :
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
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? ;)
--
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
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,
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
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
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
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,
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),
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
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
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
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,
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
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
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
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.
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:
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
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.
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
48 matches
Mail list logo
