|
@takluyver, thanks for your PR! By analyzing the history of the files in this pull request, we identified @larryhastings, @1st1 and @zestyping to be potential reviewers. |
There was a problem hiding this comment.
A part of the newline that should be removed, the rest LGTM
| lines.pop(0) | ||
| return '\n'.join(lines) | ||
|
|
||
|
|
There was a problem hiding this comment.
This new line should be removed.
| 'function, traceback, frame, or code object'.format(object)) | ||
| raise TypeError('object of type {} is not a module, class, method, ' | ||
| 'function, traceback, frame, or code object'.format( | ||
| type(object).__name__)) |
There was a problem hiding this comment.
I am sorry I did not tell you in the previous message, but I realized just now. You should align the type(object).__name__ to 'function'.
|
Can I prevail on anyone to merge this? @serhiy-storchaka , I implemented the change you suggested on the issue. |
|
Could you please take a look on this change @1st1? |
There was a problem hiding this comment.
Please add a NEWS entry using blurb.
| 'function, traceback, frame, or code object'.format(object)) | ||
| raise TypeError('object of type {} is not a module, class, method, ' | ||
| 'function, traceback, frame, or code object'.format( | ||
| type(object).__name__)) |
There was a problem hiding this comment.
Could you please change the error message to "module, class, method, function, traceback, frame, or code object was expected, got {}".
|
A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated. Once you have made the requested changes, please leave a comment on this pull request containing the phrase |
|
I have made the requested changes; please review again |
|
Thanks for making the requested changes! @serhiy-storchaka, @1st1: please review the changes made to this pull request. |
|
Merged. Thanks a lot! |
If the
TypeErroris caught and handled by calling code, there's no need to compute the object's repr for the error message - the repr may take a long time (real case encountered in IPython & Jedi), or it may throw another error.If the error results in a traceback, it will still compute the repr and produce the message as before.
I think this defensiveness is worthwhile for
inspectfunctions because, by design, we're calling them with arbitrary objects which might be badly behaved, and expecting them to be useful nonetheless.An alternative fix would be to use
object.__repr__()to always get the plain<foo object at 0x123abc...>representation.https://bugs.python.org/issue30639