Problem with using PythonWin and ActiveX COM Object

[Alex Martelli]

"William Wicker" <remove.me.wwicker at spectratechnologies.com> wrote in
message news:lkqmtsg1hmfeoj00i70n75hv33vsm661bp at 4ax.com...
    [snip]
> >It looks, specifically, as if iErr is passed by-reference; i.e., a
> >_reference_ to iErr is given to the LoadObjects method, which places
> >an error-code there (a strange thing to do in COM, although allowed;
> >normally, COM returns errors quite differently -- this looks like a
> >partial translation of some older C API...?).
> >
> I am working with a different package, but just enough of the COM
> interface includes functions with an interface like this (return
> values stuck in parameters passed by reference) to be really (REALLY)
> frustrating.

[out] and [in,out] parameters are both allowed in COM, but neither
kind is frequent in Automation-level functions, [out,retval] being
the more usual substitute.  A function with a single [out] and
without an [out,retval] is _particularly_ peculiar.


> >Python's COM interface is no doubt passing iError by value (it always
> >does: no pass-by-reference in Python!) and I think this is what the
> >Siebel object is diagnosing as a type-error.
>
> I though *everything* in Python was by-reference?

You may conceptualize the passing of an integer argument as "passing
a reference to an immutable value", if you wish, but that just doesn't
jell with what (e.g.) Visual Basic means when it distinguishes a
ByRef and ByVal argument.  Specifically, in VB:

    sub thebyval(byval x as integer)
        ...
    end sub

    sub thebyref(byref x as integer)
        ...
    end sub

    dim a as integer
    dim b as integer
    a = 23
    b = a
    call thebyval(a)
    ' now, a and b MUST still be identical
    call thebyref(a)
    ' now, a and b MIGHT differ

The behaviour of any Python function is just like that of "thebyval":
after a sequence such as
    a=23
    b=a
    thepythonfunction(a)
it MUST, always, be the case that a and b are still identical, no
matter how "thepythonfunction" is written (well... one could play
dirty tricks to find and alter the caller's namespace, maybe, but
I wouldn't recommend it!-).

So, in this context, since the actual behavior is what most other
languages mean by "call by value", the very opposite of "call by
reference", then "call by value" is the terminology I'd suggest...

In strict COM terms, "[in] arguments only" is more precise and
bereft of ambiguity.


> >Try calling LoadObjects with just one argument, the path to the file;
> >it should then *RETURN* the iError value as its *RESULT*.  I.e.,
> >change the offending line to
> >
> >    iError = objSiebel.LoadObject(r'c:\siebel\bin\psblprd.cfg')
> >
>
> I've tried this in my application, and get complaints about missing
> arguments.

Hmmm, yes, I guess it would do that, if it didn't have the type
library -- it can't know it must pass two arguments to the actual
COM method (the second one by-reference).


> >sure the genpy-supplied wrappers are used rather than purely dynamic
> >dispatching (it's a rather advisable thing anyway, in general), but I
> >think you might be able to get away without that.
>
> I haven't tried then genpy interface. That might work.

Yes, I may be wrong about the "sometimes being able to get away
without that" (or maybe it's for [in,out] parameters only, an even
rarer case).


Alex