site.abs__file__ fails for modules where __file__ cannot be modified

[AlexanderMcFarlane]

BPO	31798
Nosy	@terryjreedy, @ericvsmith

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2017-10-16.10:55:47.808>
labels = ['3.7', 'type-bug', 'library']
title = '`site.abs__file__` fails for modules where `__file__` cannot be modified'
updated_at = <Date 2017-10-20.18:41:48.517>
user = 'https://bugs.python.org/AlexanderMcFarlane'

bugs.python.org fields:

activity = <Date 2017-10-20.18:41:48.517>
actor = 'terry.reedy'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2017-10-16.10:55:47.808>
creator = 'Alexander McFarlane'
dependencies = []
files = []
hgrepos = []
issue_num = 31798
keywords = []
message_count = 4.0
messages = ['304466', '304550', '304669', '304670']
nosy_count = 3.0
nosy_names = ['terry.reedy', 'eric.smith', 'Alexander McFarlane']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'test needed'
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue31798'
versions = ['Python 2.7', 'Python 3.6', 'Python 3.7']

[AlexanderMcFarlane]

The pythonnet module clr causes a TypeError when abs__file__ attempts to run the following line:

m.__file__ = os.path.abspath(m.__file__)

Reproduction:

import clr
cls.__file__ = 'example'

[ericvsmith]

I don't have clr installed in order to test this. It would be good if you could produce it without us having to install additional software.

Could you please copy the entire stack traceback you get when this error occurs?

Does this error happen on 3.6, too?

[terryjreedy]

2.7 site module has

def abs__file__():
    """Set all module' __file__ attribute to an absolute path"""
    for m in sys.modules.values():
        if hasattr(m, '__loader__'):
            continue   # don't mess with a PEP 302-supplied __file__
        try:
            m.__file__ = os.path.abspath(m.__file__)
        except (AttributeError, OSError):
            pass

This code assumes that if an object [not coded in python] has read-only attributes, so that the attempt to write would raise TypeError, then it do not have .__file__, so there will be an AttributeError, and there will not be a TypeError to catch. This is true of CPython builtins.

>>> list.__file__
Traceback (most recent call last):
  File "<pyshell#2>", line 1, in <module>
    list.__file__
AttributeError: type object 'list' has no attribute '__file__'

>>> list.__file__ = ''
Traceback (most recent call last):
  File "<pyshell#3>", line 1, in <module>
    list.__file__ = ''
TypeError: can't set attributes of built-in/extension type 'list'

On the other hand, C-coded _tkinter has a re-writable .__file__. 
>>> import _tkinter
>>> _tkinter.__file__
'C:\\Programs\\Python27\\DLLs\\_tkinter.pyd'
>>> _tkinter.__file__ = ''

From the minimal information given, it appears that clr defies this expectation by having an unwritable .__file__ attribute. Hence the TypeError in abs_file. Unless a read_only .__file__ is somewhere documented as prohibited, the bug seems to be not including TypeError in the exception tuple.

In 3.x, abs__file__ became abs_paths. It has the same line with the same problem.

For testing, perhaps an instance of this in sys.modules would work.

class UnsettableFile:
    def __getattr__(self, name):
        return __file__
    def __setattr__(self, name, value):
        raise TypeError()