Thanks Mark, that clears up the behavior. I'd been suspicious that it was an underlying COM method but couldn't really tell from my limited understanding of Win32Com. I'd not understood the differences in printing an object and printing a list of objects, so you've improved my Python education yet again. Thanks.
Regards, Richard |-----Original Message----- |From: Mark Hammond [mailto:[EMAIL PROTECTED] |Sent: Thursday, July 05, 2007 6:41 PM |To: 'Richard Bell'; python-win32@python.org |Subject: RE: [python-win32] Strange/impossible Python COM interface |behavior | |> Several things caught my attention about this. |> |> First, the attempt to print qNode (an object of class |> win32com.gen_py.3050F1C5-98B5-11CF-BB82-00AA00BDCE0Bx0x4x0.Dis |> pHTMLInputElem |> ent) produces a zero length string. However print of nodes |> for other HTML |> tags such as HTML, BODY, or DIV produces strings that |> describe the object. | |Yes - as I mentioned before, str(ob) calls a COM method on 'ob' - so what |'print ob' yields is up to the object, not up to win32com. | |> Second, when the INPUT node named 'q' is returned as an item |> in a list (see |> qNode2) printing the list prints the item. I'm not sure |> what's different |> about printing an item in a list vs printing the item, but |> clearly something |> different is involved even though the underlying object is of |> the same type. | |This is just Python. When you 'print ob', you are doing, basically, print |str(ob). But when ob is a list, the list object itself uses repr() on the |list elements. So if 'ob' is in a list, you get different results than if |it is not. This is Python, not win32com. | |Mark _______________________________________________ Python-win32 mailing list Python-win32@python.org http://mail.python.org/mailman/listinfo/python-win32
