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.

Title: inspect.getfile(obj) calls object repr on failure
Type: enhancement Stage: resolved
Components: Library (Lib) Versions: Python 3.7
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: r.david.murray, serhiy.storchaka, takluyver, yselivanov
Priority: normal Keywords: easy

Created on 2017-06-12 13:54 by takluyver, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 2132 merged takluyver, 2017-06-12 15:42
Messages (9)
msg295782 - (view) Author: Thomas Kluyver (takluyver) * Date: 2017-06-12 13:54
This came up in IPython & Jedi: several functions in inspect end up calling getfile(). If the object is something for which it can't find the source file, it throws an error, the message for which contains the object's repr.

This is problematic for us because for some objects the repr may be expensive to calculate (e.g. data tables where the repr forms primary output, not just debugging information). In some cases, it could also throw another error.

I plan to make a PR for this, but I'm opening an issue so I've got a bpo number.
msg295792 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2017-06-12 14:50
What is your proposed solution?  This doesn't at the moment sound like a bug in Python to me.
msg295796 - (view) Author: Thomas Kluyver (takluyver) * Date: 2017-06-12 15:36
Not exactly a bug, but I think that an improvement is possible. My plan is to delay computing the repr until the error is formatted, so that code which catches the TypeError can carry on safely.

I think this is more relevant for inspect than for many other modules, because by design, we're often calling inspect functions on arbitrary objects which we can make few guarantees about.
msg295807 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2017-06-12 17:50
I think in that case it is enough to report just type name.
msg295808 - (view) Author: Thomas Kluyver (takluyver) * Date: 2017-06-12 17:54
Sure, I can do that if you want. The other thing I thought of was using object.__repr__, so the repr always shows like <foo object at 0x123abc...> .
msg295809 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2017-06-12 17:56
The address of the object is not informative. The possibility of getting a source file is determined by the type of the object.
msg295811 - (view) Author: Thomas Kluyver (takluyver) * Date: 2017-06-12 19:14
OK, I've updated the PR to do that.
msg304903 - (view) Author: Yury Selivanov (yselivanov) * (Python committer) Date: 2017-10-24 12:42
New changeset e968bc735794a7123f28f26d68fdf5dc8c845280 by Yury Selivanov (Thomas Kluyver) in branch 'master':
bpo-30639: Lazily compute repr for error (#2132)
msg304905 - (view) Author: Yury Selivanov (yselivanov) * (Python committer) Date: 2017-10-24 12:43
Thank you, Thomas.
Date User Action Args
2022-04-11 14:58:47adminsetgithub: 74824
2017-10-24 12:43:35yselivanovsetstatus: open -> closed
resolution: fixed
messages: + msg304905

stage: resolved
2017-10-24 12:42:38yselivanovsetnosy: + yselivanov
messages: + msg304903
2017-06-12 19:14:17takluyversetmessages: + msg295811
2017-06-12 17:56:55serhiy.storchakasetmessages: + msg295809
2017-06-12 17:54:19takluyversetmessages: + msg295808
2017-06-12 17:51:40serhiy.storchakasetkeywords: + easy
2017-06-12 17:50:49serhiy.storchakasetversions: + Python 3.7
nosy: + serhiy.storchaka

messages: + msg295807

type: behavior -> enhancement
2017-06-12 15:42:31takluyversetpull_requests: + pull_request2186
2017-06-12 15:36:05takluyversetmessages: + msg295796
2017-06-12 14:50:55r.david.murraysetnosy: + r.david.murray
messages: + msg295792
2017-06-12 13:54:06takluyvercreate