This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Class name hardcoded in TracebackException.from_exception()
Type: enhancement Stage: resolved
Components: Library (Lib) Versions: Python 3.6, Python 3.5
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: berker.peksag, python-dev, rbcollins, serhiy.storchaka, yselivanov
Priority: normal Keywords: patch

Created on 2015-07-24 22:57 by berker.peksag, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
classmethod.diff berker.peksag, 2015-07-24 22:57 review
classmethod_2.patch serhiy.storchaka, 2015-07-25 19:01 review
Messages (9)
msg247301 - (view) Author: Berker Peksag (berker.peksag) * (Python committer) Date: 2015-07-24 22:57
Here is a patch that changes to use cls() instead of hardcoded TracebackException.

Serhiy also suggested on IRC to use the from_exception() classmethod in TracebackException's __init__ method.
msg247367 - (view) Author: Robert Collins (rbcollins) * (Python committer) Date: 2015-07-25 18:49
We can't use from_exception in __init__ because from_exception's job is to look up __traceback__, but the legacy API allows arbitrary tb objects which may not be exc.__traceback__, and modifying exc.__traceback__ or creating a shim object just to be able to use from_exception doesn't make sense to me.

This patch looks good, and I'm applying to 3.6. It has no functional impact (except for perhaps weird mocking corner cases, but as its a pure class that shouldn't be needed), so I'm leaving it out of 3.5, since i'm not 100% sure where the move to a new repo is at, and its not worth figuring that out.
msg247368 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2015-07-25 18:51
New changeset 1be4d7388279 by Robert Collins in branch 'default':
Issue #24710: Use cls in TracebackException.from_exception.
https://hg.python.org/cpython/rev/1be4d7388279
msg247369 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2015-07-25 18:56
We can use from_exception() in __init__ because in both cases first three arguments of TracebackException() are type(e), e, e.__traceback__. Without this change changing from_exception() makes less sense.

Here is a patch.
msg247380 - (view) Author: Robert Collins (rbcollins) * (Python committer) Date: 2015-07-25 19:17
Oh I see, - different things could have been meant but that application will work.

But - please don't use self.from_exception: its a class method, so TracebackException.from_exception(...) is the right spelling.
msg247382 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2015-07-25 19:24
self.from_exception() works as well.
msg247386 - (view) Author: Robert Collins (rbcollins) * (Python committer) Date: 2015-07-25 19:54
I know it 'works', I just think its not appropriate here.
msg248788 - (view) Author: Yury Selivanov (yselivanov) * (Python committer) Date: 2015-08-18 18:55
LGTM.

FWIW, using 'self.from_exception(..)' is better because this way it's easier to override the method.  Another way would be to write 'type(self).from_exception(..)', but I think using 'self' is good enough.
msg248861 - (view) Author: Robert Collins (rbcollins) * (Python committer) Date: 2015-08-19 23:01
So I'm still ambivalent at best about this - this interface hasn't been designed for subclassing - I'm sure there is a bunch more stuff that would be needed. What /is/ needed feature wise here is a sideways extension mechanism for doing filtering and transformation of frames.

I'd be much happier about looking at subclassability after we had that in place.

Anyhow, since I did apply the change this issue was specifically about (the third hunk in the patches), I'm going to close this now.
History
Date User Action Args
2022-04-11 14:58:19adminsetgithub: 68898
2015-08-19 23:01:07rbcollinssetstatus: open -> closed
resolution: fixed
messages: + msg248861

stage: patch review -> resolved
2015-08-18 18:55:09yselivanovsetnosy: + yselivanov
messages: + msg248788
2015-07-25 19:54:05rbcollinssetmessages: + msg247386
2015-07-25 19:24:56serhiy.storchakasetstatus: closed -> open
resolution: fixed -> (no value)
stage: resolved -> patch review
2015-07-25 19:24:12serhiy.storchakasetmessages: + msg247382
2015-07-25 19:17:43rbcollinssetmessages: + msg247380
2015-07-25 19:01:58serhiy.storchakasetfiles: - classmethod_2.patch
2015-07-25 19:01:51serhiy.storchakasetfiles: + classmethod_2.patch
2015-07-25 18:56:36serhiy.storchakasetfiles: + classmethod_2.patch

messages: + msg247369
2015-07-25 18:51:45rbcollinssetstatus: open -> closed
resolution: fixed
stage: patch review -> resolved
2015-07-25 18:51:12python-devsetnosy: + python-dev
messages: + msg247368
2015-07-25 18:49:14rbcollinssetmessages: + msg247367
2015-07-24 22:57:05berker.peksagcreate