[IronPython] Patching __import__ can break .NET attribute access

Dino Viehland dinov at microsoft.com
Sat Mar 7 20:55:50 CET 2009


Yep, that's definitely a problem and definitely a good reason to make it a compile time hook instead.  Another reason is that when the import code is written entirely in Python we'll have the same problem.

> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-
> bounces at lists.ironpython.com] On Behalf Of Michael Foord
> Sent: Saturday, March 07, 2009 11:51 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Patching __import__ can break .NET attribute
> access
> 
> 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.
> 
> Michael
> 
> >> -----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
> >> access
> >>
> >> 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
> >> run:
> >>
> >>     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,
> >>
> >> Michael
> >> --
> >> http://www.ironpythoninaction.com/
> >>
> >>
> >
> > _______________________________________________
> > Users mailing list
> > Users at lists.ironpython.com
> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> >
> 
> 
> --
> http://www.ironpythoninaction.com/
> http://www.voidspace.org.uk/blog
> 
> 
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com



More information about the Ironpython-users mailing list