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

Cesar Koers ckoers at fulladsl.be
Wed Mar 14 08:08:29 CET 2007 

'Element' and 'Text' both derive from 'Node', which does not derive from anything and is described as "Abstract base class of nodes in a document tree."

I don't know if the immediate window should normally be able to interpret 'len', so I don't know if this is a sign of something wrong: I tried to evaluate the value of 'len(self.children)' on line 233 
with the VS debugger. When it breaks at line 466 (where the exception is raised) and I go back one step in the call stack to line 234 (just after the 'len' check), I get in the immediate window:

 >> len(self)
'docutils.nodes.len' is a 'field' but is used like a 'method'
 >> len(self.children)
'docutils.nodes.len' is a 'field' but is used like a 'method'
 >> self
{<paragraph>Something to publish</paragraph>}
 >> self.parent
'object' does not contain a definition for 'parent'
 >> self.children
'object' does not contain a definition for 'children'



Dino Viehland wrote:
> Unfortunately I don't know if I can actually look at the docutils code :(.  I'll have to ping some people if this doesn't get us to the bottom of it (the license isn't entirely clear to me from http://docutils.sourceforge.net/ either).  The good news is I think I know the problem now so hopefully one more question will confirm this.
> 
> I suspect the problem here is that we're not properly supporting overriding __len__ (similar to the bug we have against overriding __contains__).
> 
> I think this is the bug:
> 
> for x in (tuple, list, dict):
>     class subtype(x):
>             def __len__(self): return 42
>     print len(subtype())
> 
> In CPython this prints 42 3 times and in IP it prints 0 3 times.  Can you just confirm that Element and Text derive from some other type like tuple, list, or dict or if not one of those can you let us know what they derive from?
> 
> If this is the same bug as __contains__ I think I'm going to try and fix it for v1.1 final.
> 
> -----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:53 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Using python docutils from C# - difference between shell and embedded engine?
> 
> 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
>>
>>
> _______________________________________________
> 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