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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Cesar Koers >> Sent: Tuesday, March 13, 2007 3:13 AM >> To: users@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@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 >> >> > _______________________________________________ > 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 > > _______________________________________________ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com