No, it doesn't. Other than optionally providing a type library (which we don't provide) all IDispatch does is name->ID lookup, and invoke a method/property via ID.
Python is making unwarranted assumptions about whether a particular "name" equates to a method or property rather than using the context provided by the code.
"and invoke a method/property via ID" ... with wFlags, which is there for a reason.
OK, I see you are probably not willing to fix this for whatever reason, but at least there is workaround. BTW, problem is also present for any function that can accept 0 parameters, but also more, like Vector. So not just for objects that are like properties.
FYI, about the context provided by code:
When executing object.somefunc(), which is always so in Python, even if the "object." part is assumed, Python:
- Asks object for attribute somefunc (which is an object)
- Executes () operator on the obtained somefunc. This is can be done if somefunc's type is (descendant of) class function or has call() implemented.
In case of COM, in order to use a function provided by IDispatch, pywin constructs function from on object provided by COM. Now imagine something like this: I have in my program "DOpus.language()". pywin gets object provided by IDIspatch, constructs function object (body) and runs it. See the problem?
In order to avoid such situations, and determine what COM server author has on mind, pywin first calls IDispatch with DISPATCH_PROPERTYGET to check what an object is for. And that's it.
Probably JS or VBS just call everything anyways - some accessor in case of properties, so they are resistant to wFlags inconsistencies.
My 2 cents: It's up to ActivePython to behave like an ActiveScripting language, consistent with the other ones. It's not up to everything else to change for Python. This might be different if using Python in this domain was something lots of people were interested in, but it seems to be literally just you, against our advice, and each time one issue has been fixed two more are found afterwards (as I predicted months ago).
With one scripting language mastered already, JScript and VBScript will take a couple of hours to learn, tops. You could've gotten up to speed with both several times now for all the time you and Jon have spent trying to fit the square peg of Python into the round hole of ActiveScripting. And as a bonus you can use bits of other people's code from the forum, and you can share your code on the forum for people to use without having to install an extra language.
That's not what DISPATCH_PROPERTYGET does. It doesn't get you the properties of an object. It gets a property provided by an object. It returns data, not metadata.
Jon, I know. If you has a better way to tell properties from methods having only IDispatch interface, please let me know. I will make corrections in pywin method detection myself.
Leo, if you take a look at the older posts, you should see that there was interest in Python. And it's hard to wonder it waned since, as it makes problems at the very first touch. And I really select tools for problems, not the other way round.
As I've noted, there is workaround, so I guess this discussion is concluded now.
You can tell by the context of how it's used. This is what JScript and VBScript do.
x = object.name; // property
x = object.name(); // method