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: inspect.getsource(), P302 loader and '<..>' filenames
Type: behavior Stage:
Components: Library (Lib) Versions: Python 3.3, Python 3.4, Python 2.7
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: eric.snow, r.david.murray, serhiy.storchaka, stefan.mueller
Priority: normal Keywords:

Created on 2014-01-09 13:18 by stefan.mueller, last changed 2022-04-11 14:57 by admin.

Messages (3)
msg207736 - (view) Author: Stefan Müller (stefan.mueller) Date: 2014-01-09 13:18
Following situation

* python 2.7.6

* module loaded via a PEP302 loader.

* the loader has get_source(fullname)

* assigns a dummy string as a file: module.__file__ == "<mymodule>"

Then

inspect.getsource(module)

throws

IOError: could not get source code

I tired to track this down, and it seems to be caused by  linecache.updatecache(..) with has

    if not filename or (filename.startswith('<') and filename.endswith('>')):
        return []

at the beginning.

This seems too restrictive me. Without the 'if' it would try to read the file from disk, and if that fails check if there is a loader, without a loader it returns [], so there would not be any behaviour change for non-loader modules if the 'if' was removed, only an additional disk access.

I suggest to remove the 'if'.

Workaround: Don't use '<>' for the dummy file name, but I've read somewhere that those '<>' are a convention for such use-cases.
msg207766 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2014-01-09 18:18
There would be behavior change if file '<mymodule>' exists.
msg207772 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2014-01-09 18:58
Maybe the logic needs to be reordered: look for a loader first, before looking for a file on disk.  It seems to me the current lookup order might itself be a bug.

Note that the code is the same in python3, so the issue exists there as well.
History
Date User Action Args
2022-04-11 14:57:56adminsetgithub: 64404
2020-03-18 18:34:51brett.cannonsetnosy: - brett.cannon
2014-01-09 18:58:35r.david.murraysetnosy: + brett.cannon, eric.snow

messages: + msg207772
versions: + Python 3.3, Python 3.4
2014-01-09 18:18:37serhiy.storchakasetnosy: + serhiy.storchaka
messages: + msg207766
2014-01-09 15:37:10r.david.murraysetnosy: + r.david.murray
2014-01-09 13:18:49stefan.muellercreate