Python COM - limit on size/complexity of returned object?

[Paul Keating]

kveretennicov at yahoo.com (Konstantin Veretennicov) wrote in message news:<5155aad2.0406250612.29d5039b at posting.google.com>...

> Well, I did some testing with python 2.3 (that's what I have).
> Not sure if it will cheer you up, but I had no problems.

Thanks for the pointer. I tried it on another machine with 2.3 and
that works with no problems.

And I made some further discoveries on the 2.2 side: the problem isn't
a limit on the size of the returned object, it's cumulative. I amended
GetProfileComponentMatrixEx() to return the first n rows of the
matrix, to find out what the limit was: like this
>>> print len(GetProfileComponentMatrixEx(10))
10
>>> print len(GetProfileComponentMatrixEx(40))
40
>>> print len(GetProfileComponentMatrixEx(80))
<GPF!>
But trying it repeatedly I found that I could only execute the
following line once: it crashed calling it with an argument of 40 the
second time:
>>> print len(GetProfileComponentMatrixEx(40))
40
>>> print len(GetProfileComponentMatrixEx(40))
<GPF!>
And then I tried this repeatedly:
>>> print len(GetProfileComponentMatrixEx(10))
and -- surprise! -- it failed about the 7th or 8th invocation.

So, now there are two possibilities. 
1. It's a 2.2 problem that is fixed in 2.3 (though I looked in
Sourceforge for the bug reports and this did not show up there).
2. It's a side-effect of the module I'm importing to do the actual
work. On the machine running 2.3, I had to write a stub to represent
this module, because it is a home machine that can't see the work
server where the data is.

If the DLL is at fault, I'm going to have a hard time convincing the
vendor that they have to fix it. If I were them, I'd be sceptical. The
DLL is loaded by the import statement, but in this test it is never
called. It's hard to see what it's initialization code could possibly
be doing to break pythoncom.