Modification of __builtin__.file breaks assumptions of client code for __builtin__.file
Issue #22
resolved
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)
-
-
- changed status to open
-
@marc_valle Can you confirm this is addressed in the last official drop with python3. I believe the new way files are handled in py3 should address this problem.
-
- changed status to resolved
The move to Python 3 solves this issue.
- Log in to comment
Hi @marc_valle, thank you for figure out the issue and such complete bug report. I have created a pull-request to fix the issue. Now please wait for @dragon512 to review it.