[IronPython] Exceptions Running nose and IronPython

[Darrell Hawley]

I was talking to some of the Dynamic folks at the Microsoft MVP Summit about
my experience using nose in IronPython. I blogged about it and sent a link
to both Harry P. and Michael Foord, but I left everyone else out. You can
find my original post at
http://srtsolutions.com/blogs/darrellhawley/archive/2009/03/06/running-nose-with-ironpython.aspx
.

Just so you don't have to go clicking on links, here's my script:

import sys
sys.path.append(r"C:\Python25\Lib\site-packages\nose-0.10.4-py2.5.egg")
sys.path.append(r"C:\python25\lib")
sys.path.append(r"C:\Python25\Lib\email")
sys.path.append(r"C:\Python25\Scripts")
import nose
nose.main()

Performance is awful probably due to the number of GeneratorExitExceptions
being thrown. If anyone has any ideas, I'd love to hear them.

Darrell Hawley
SRT Solutions
www.srtsolutions.com
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Exceptions Running nose and IronPython

[Dino Viehland]

I can't run it right now but if these are happening on the finalizer thread 
then this has most likely been fixed in the 2.6 branch already.  The issue is 
that when a generator is not run to exhaustion we need to call close() on it 
which causes an exception to be thrown.  But we can avoid the exception if the 
generator has no except/finally blocks as no user code will run when the throw 
occurs.

From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Darrell Hawley
Sent: Saturday, March 07, 2009 8:11 AM
To: IronPython Mailing List
Subject: [IronPython] Exceptions Running nose and IronPython

I was talking to some of the Dynamic folks at the Microsoft MVP Summit about my 
experience using nose in IronPython. I blogged about it and sent a link to both 
Harry P. and Michael Foord, but I left everyone else out. You can find my 
original post at 
http://srtsolutions.com/blogs/darrellhawley/archive/2009/03/06/running-nose-with-ironpython.aspx.

Just so you don't have to go clicking on links, here's my script:
import sys
sys.path.append(r"C:\Python25\Lib\site-packages\nose-0.10.4-py2.5.egg")
sys.path.append(r"C:\python25\lib")
sys.path.append(r"C:\Python25\Lib\email")
sys.path.append(r"C:\Python25\Scripts")
import nose
nose.main()

Performance is awful probably due to the number of GeneratorExitExceptions 
being thrown. If anyone has any ideas, I'd love to hear them.

Darrell Hawley
SRT Solutions
www.srtsolutions.com
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Patching __import__ can break .NET attribute access

[Dino Viehland]

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.

> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@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@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] dir returning protected members

[Dino Viehland]

This is the correct behavior.  We expose protected members as normal members 
that throw when the instance isn't a subclass defined in Python.  But they need 
to exist on the base class so that you can do things like super calls to them.

> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Kamil Dworakowski
> Sent: Friday, March 06, 2009 3:05 AM
> To: users@lists.ironpython.com
> Subject: [IronPython] dir returning protected members
> 
> For my purpose this is bad that dir returns protected members, but I
> don't know if it is a bug. Is it a bug?
> ___
> Users mailing list
> Users@lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Patching __import__ can break .NET attribute access

[Michael Foord]

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-boun...@lists.ironpython.com [mailto:users-
boun...@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@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@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Patching __import__ can break .NET attribute access

[Dino Viehland]

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-boun...@lists.ironpython.com [mailto:users-
> boun...@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-boun...@lists.ironpython.com [mailto:users-
> >> boun...@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@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@lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] dir returning protected members

[Kamil Dworakowski]

Is there a way to check if it is a protected member or not?

On Mar 7, 7:49 pm, Dino Viehland  wrote:
> This is the correct behavior.  We expose protected members as normal members 
> that throw when the instance isn't a subclass defined in Python.  But they 
> need to exist on the base class so that you can do things like super calls to 
> them.
>
> > -Original Message-
> > From: users-boun...@lists.ironpython.com [mailto:users-
> > boun...@lists.ironpython.com] On Behalf Of Kamil Dworakowski
> > Sent: Friday, March 06, 2009 3:05 AM
> > To: us...@lists.ironpython.com
> > Subject: [IronPython] dir returning protected members
>
> > For my purpose this is bad that dir returns protected members, but I
> > don't know if it is a bug. Is it a bug?
> > ___
> > Users mailing list
> > us...@lists.ironpython.com
> >http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
> ___
> Users mailing list
> us...@lists.ironpython.comhttp://lists.ironpython.com/listinfo.cgi/users-ironpython.com
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] dir returning protected members

[Dino Viehland]

In the 2.6 branch there is.  After importing clr there's an Overloads property 
on built-in functions (that's been there for a while).  In 2.6 off of the 
overloads object there is a Targets property which includes all of the CLR 
MethodBase objects.  You can check the IsFamily, IsFamilyOrAssembly, or 
IsFamilyAndAssembly properties.  IsFamily is protected, IsFamilyOrAssembly is 
C#'s protected internal - basically protected to you, IsFamilyAndAssembly is 
basically an internal method to you (I'm not sure what languages expose this, 
C# doesn't).

> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Kamil Dworakowski
> Sent: Saturday, March 07, 2009 12:35 PM
> To: users@lists.ironpython.com
> Subject: Re: [IronPython] dir returning protected members
> 
> Is there a way to check if it is a protected member or not?
> 
> On Mar 7, 7:49 pm, Dino Viehland  wrote:
> > This is the correct behavior.  We expose protected members as normal
> members that throw when the instance isn't a subclass defined in
> Python.  But they need to exist on the base class so that you can do
> things like super calls to them.
> >
> > > -Original Message-
> > > From: users-boun...@lists.ironpython.com [mailto:users-
> > > boun...@lists.ironpython.com] On Behalf Of Kamil Dworakowski
> > > Sent: Friday, March 06, 2009 3:05 AM
> > > To: us...@lists.ironpython.com
> > > Subject: [IronPython] dir returning protected members
> >
> > > For my purpose this is bad that dir returns protected members, but
> I
> > > don't know if it is a bug. Is it a bug?
> > > ___
> > > Users mailing list
> > > us...@lists.ironpython.com
> > >http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> >
> > ___
> > Users mailing list
> >
> us...@lists.ironpython.comhttp://lists.ironpython.com/listinfo.cgi/user
> s-ironpython.com
> ___
> Users mailing list
> Users@lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com