I seem to have fixed it btw but in a different way. All I did was to cast the object to a string and this seems to have fixed the problem: data=str(self.the_docs.xml.data) This should work for all the files that I'm interested in, so until it breaks I'll leave it that way. Phil phil.harris@zope.co.uk |>-----Original Message----- |>From: Michel Pelletier [mailto:michel@digicool.com] |>Sent: Tuesday, December 21, 1999 2:46 PM |>To: 'Phil Harris'; Michel Pelletier; Zope@zope.org |>Subject: RE: [Zope] Part-time tracebacks |> |> |> |> |>> -----Original Message----- |>> From: Phil Harris [mailto:phil.harris@zope.co.uk] |>> Sent: Tuesday, December 21, 1999 9:20 AM |>> To: Michel Pelletier; Zope@zope.org |>> Subject: RE: [Zope] Part-time tracebacks |>> |>> |>> Right..... |>> |>> But why would documents of exactly the same Zope type and content-type |>> behave differently??? |> |>I don't know, perhaps all the objects your external method is chewing |>(I'm assuming an EM here) are not all objects if the same type, it's |>happened to me... |> |>My wrapped object suggestion may not be the case, but that's what it |>looks like from your traceback. What might be useful is to fire up Zope |>in DeBug mode and wrap your code with something like: |> |> try: |> pass # your code here... |> except: |> import pdb |> pdb.set_trace() |> |>When an exception gets raised, you'll find your Zope in the python |>debugger waiting for input (all other Zope services will be locked out, |>BTW). Now you can inspect your object to see what it really is: |> |>pdb> p obj |><DTMLMethod instance at 8403ed8> |>pdb> type(obj) |><extension class Acquisition.ImplicitAcquirerWrapper at 400fa3b0> |>pdb> |> |>etc... at this point it's kinda fun (in my sick and twisted world) to |>play around with the obj in question, examining all of its various aq_ |>properties, like aq_self, aq_parent, aq_inner, aq_inContextOf, and |>aq_uncle. |> |>> These were all File with a type of text/xml, so why the difference??? |> |>Not sure. |> |>-Michel |>