[IronPython] Patching __import__ can break .NET attribute access
fuzzyman at voidspace.org.uk
Sat Mar 7 20:50:58 CET 2009
Dino Viehland wrote:
> This one is technically by design. The python code which calls __import__/does import is the one that gets tainted with the ability to see clr attributes. We have discussed changing the design so that "import clr" is recognized at compile time and works like from __future__ ... instead of being a runtime feature. If we were to make that change it'd also mean "import System" wouldn't bring in .NET attributes either. But that'd probably be something for IronPython 3k as it's a fairly significant breaking change. It'd be interesting to hear if people would like one way over the other.
The difficulty is that adding an (apparently innocuous) import hook in
your code can break third party code (in the form of compiled IronPython
modules) which you may not have the source code to.
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com [mailto:users-
>> bounces at lists.ironpython.com] On Behalf Of Michael Foord
>> Sent: Friday, March 06, 2009 6:41 AM
>> To: Discussion of IronPython
>> Subject: [IronPython] Patching __import__ can break .NET attribute
>> Hello all,
>> If you patch __builtin__.__import__, even with something that delegates
>> to the real __import__, then accessing .NET attributes can break.
>> Attached are two Python files, place them in the same directory and
>> ipy first.py
>> and get this error:
>> Traceback (most recent call last):
>> File "first.py", line 12, in first.py
>> File "C:\buildshare\test.py", line 6, in function
>> AttributeError: 'int' object has no attribute 'MaxValue'
>> All it does is patch __import__ so that all imports are printed.
>> This is with Python 2.0.1.
>> All the best,
> Users mailing list
> Users at lists.ironpython.com
More information about the Ironpython-users