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.