Modification of builtin.file breaks assumptions of client code for builtin.file

The following sconstruct will fail to compile with a python error:

from parts import *
item = []
if isinstance(item, (unicode, bytes, bytearray,
                     str, file)):
    print "YES:"
else:
    print "NO:"

Output:

scons all
scons: Reading SConscript files ...
TypeError: isinstance() arg 2 must be a class, type, or tuple of classes and types:
  File "SConstruct", line 35:
    str, file)):

The reason appears to be due to overriding of builtin.file in os_file.py.

The workaround if one knows about this is the following:

from SCons.Script import _SConscript
import __builtin__
from parts import *
item = []

_original_file = __builtin__.file
__builtin__.file = _SConscript.file
if isinstance(item, (unicode, bytes, bytearray,
                    str, _SConscript.file)):
    print "YES:"
else:
    print "NO:"
__builtin__.file = _original_file

This is non-obvious and surprising to users, especially when a user may be calling code from a python module they did not develop (this was discovered when developing a builder for robot framework -- a similar construct code appears deep inside this third party code).

Can isinstance be made to work on shared_open?

Comments (4)