[IronPython] Using python docutils from C# - difference between shell and embedded engine?

Cesar Koers ckoers at fulladsl.be
Tue Mar 13 21:53:05 CET 2007


In module nodes.py (see http://svn.berlios.de/viewcvs/docutils/trunk/docutils/docutils/nodes.py?rev=4649&view=markup)

The 'len' check is in class 'Node', method 'traverse', starting on line 233:

if descend and len(self.children):
     for child in self:
         r.extend(child.traverse(include_self=1, descend=1, siblings=0, ascend=0, condition=condition))

'children' should be of type 'Element' or 'Text' (see class 'Element' line 375)

The iteration results in a call to Element.__getitem__, which raises the TypeError exception when the code starting on line 465 is executed:

elif isinstance(key, IntType):
     return self.children[key]


There is no indication in ipy that this code behaves unexpectedly. It seems hard to believe that the same code would not work in CPython (didn't check that though).


Please mind that I have no ambition to hack on IronPython, just getting docutils to work will be just fine. For that matter, I'm not even a Python programmer, so hacking on docutils seems unreasonable 
too. Nevertheless, if this can help improve IronPython great!



Dino Viehland wrote:
> What is the type of children and how does it check the len?  Maybe there's something wrong or broken on our side which is leading us down to this code path.  It could also be that the exception shouldn't occur but there's something wrong in the Python code that causes us to get to the exception (and would presumably do the same on CPython).
> 
> Otherwise if the exception occurs on both CPython and IP then I think the IndexOutOfRangeException is correct.  VS does have a "Just My Code" feature so depending on if you're trying to debug IP or a mix of Python code and your own C# code you might find your experience to be better if you don't build IP.  Instead just debug your Python code & C# code against the released binaries (or your own build w/o PDBs).  Without the PDBs for the IP code VS should then only recognize the Python code and your C# and only show you the exceptions coming from your code.  Obviously if you're hacking on the IP runtime this doesn't help you :).
> 
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Cesar Koers
> Sent: Tuesday, March 13, 2007 1:07 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Using python docutils from C# - difference between shell and embedded engine?
> 
> Thanks for pointing me in the right direction. Although unchecking
> everything in the Debug->Exceptions "thrown" column does not change the
> described behaviour.
> 
> The stacktrace showed that the particular python exception thrown
> inherited from System.IndexOutOfRangeException. Unchecking
> "User-unhandled" for that exception does the trick.
> 
> I am not sure if this is desired behaviour, as I believe that the same
> exception could easily be raised in C# code - not causing the debugger
> to break with these settings.
> 
> Running in Release mode goes fine (the fact that it hung before was
> probably due to interference with NUnit).
> 
> 
> 
> Dino Viehland wrote:
>> Could it be that you have 1st chance exceptions enabled and this exception is actually handled and recovered from?  Python programs tend to throw exceptions more than your typical C# app.  Given that stepping out seems to allow the program to complete this sounds like what's happening.
>>
>> You can disable 1st chance exceptions w/ Debug->Exceptions and then uncheck anything checked in the "Thrown" column.  Leave "User Unhandled" checked.
>>
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Cesar Koers
>> Sent: Tuesday, March 13, 2007 3:13 AM
>> To: users at lists.ironpython.com
>> Subject: [IronPython] Using python docutils from C# - difference between shell and embedded engine?
>>
>> Hi all,
>>
>> I could use some help with embedding Python docutils
>> (http://docutils.sourceforge.net/) with C#. At this point, I'm able to
>> use the 'docutils.core.publish_string' function from the ipy.exe shell
>> with decent output.
>>
>> However, when embedding the PythonEngine in my C# app, and executing
>> 'docutils.core.publish_string' with the exact same arguments (*),
>> execution stops at a "raise TypeError" in Python code (in Debug mode, in
>> Release mode I believe it doesn't return from the Python code at all).
>> Repeatedly stepping out of the Python code (10-15 times) with the
>> debugger finishes the program.
>>
>> VS shows that the TypeError is caused by indexing a null array (named
>> 'children'). When examining the call stack though, I understood that the
>> program shouldn't even reach this code because it first checks the value
>> of 'len(children)' before accessing 'children'.
>>
>>
>> Could there be a problem with environment settings or something? I
>> compared path and loaded modules between ipy.exe session and embedded
>> engine; there are some differences which i can't explain.
>>
>>
>> Best regards,
>>
>> C
>>
>> (*) note that importing docutils.core requires executing
>> PythonEngine.InitializeModules first and
>> PythonEngine.Import("docutils.core") is not a substitute for
>> PythonEngine.Execute("import docutils.core")
>>
>>
>>
>> PS: using "IronPython Community Edition r5" and VS Express 2005
>> _______________________________________________
>> users mailing list
>> users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>> _______________________________________________
>> users mailing list
>> users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>>
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> _______________________________________________
> 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