'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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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: [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: [email protected]
>>> 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
>>> [email protected]
>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>> _______________________________________________
>>> users mailing list
>>> [email protected]
>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>
>>>
>> _______________________________________________
>> users mailing list
>> [email protected]
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>> _______________________________________________
>> users mailing list
>> [email protected]
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>>
> _______________________________________________
> users mailing list
> [email protected]
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> _______________________________________________
> users mailing list
> [email protected]
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
_______________________________________________
users mailing list
[email protected]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
