win32com/server/policy.py tries to call as string
Note that issues in this repository are only for bugs or feature requests in the pywin32.
If you need support or help using this package, please follow these instructions - support or help requests will be closed without comment.
For all bugs, please provide the following information.
- Expected behavior and actual behavior.
https://github.com/mhammond/pywin32/blob/main/com/win32com/server/policy.py tries to call error which is a string.
error is defined at https://github.com/mhammond/pywin32/blob/e1c0237a6897dbc4adbfda6470711fade43228b7/com/win32com/server/policy.py#L103
and there are 4 instances where it is called
- https://github.com/mhammond/pywin32/blob/e1c0237a6897dbc4adbfda6470711fade43228b7/com/win32com/server/policy.py#L211
- https://github.com/mhammond/pywin32/blob/e1c0237a6897dbc4adbfda6470711fade43228b7/com/win32com/server/policy.py#L363
- https://github.com/mhammond/pywin32/blob/e1c0237a6897dbc4adbfda6470711fade43228b7/com/win32com/server/policy.py#L517
- https://github.com/mhammond/pywin32/blob/e1c0237a6897dbc4adbfda6470711fade43228b7/com/win32com/server/policy.py#L740
- Steps to reproduce the problem.
Try to use a COM interface that does not exist.
program output:
pythoncom error: ERROR: server.policy could not create an instance.
Traceback (most recent call last):
File "C:\Users\david\AppData\Local\pypoetry\Cache\virtualenvs\winsdk1-vNE5bx4W-py3.10\lib\site-packages\win32com\server\policy.py", line 151, in CreateInstance
return retObj._CreateInstance_(clsid, reqIID)
File "C:\Users\david\AppData\Local\pypoetry\Cache\virtualenvs\winsdk1-vNE5bx4W-py3.10\lib\site-packages\win32com\server\policy.py", line 211, in _CreateInstance_
raise error(
TypeError: 'str' object is not callable
pythoncom error: CPyFactory::CreateInstance failed to create instance. (80004005)
- Version of Python and pywin32
These kinds of issues are easily caught by type-checkers. I also noticed a couple more error; str in typeshed recently. I expect this to be resolved pretty soon as I turn on type-checking for more and more parts of the code.
@mhammond It seems that during the transition to Python3, a lot of string error variables were left as strings, causing them to be called and raise TypeError: 'str' object is not callable. What should be done with those?
- Make them their own
errorclass, possibly inheriting fromTypeErrorfor historical reasons to prevent breaking any code that expects the incorrectTypeErrorto be re-raised? - Just use
Exceptiondirectly instead (raising bare Exceptions isn't great, and pywin32 only have those in tests) - Re-use an existing exception (
pywintypes.error?) - Other?
Fixing this will be necessary to enable the reportCallIssue check in pyright.
@mhammond I can fix this, but I'm not sure what your preferred approach would be.
These are not exceptions we expect to actually hit or have people catch, so I'd be fine with one of RuntimeError, TypeError or ValueError depending on the scenario - most of the above are probably TypeError I guess? Although ValueError would still be a candidate even though we are dealing with types (ie, in most cases the user isn't specifying the wrong type necessarily, but rather the type doesn't have what we expect.)
I'm open to ideas though - WDYT?
I think that's gonna have to be a case-by-case.
First thing I noticed is that tests could simply use assert/AssertionError, that'll already safely take care of a handful of these and reduce the scope.
I noticed a few more that can sensibly be COMException instead.
Others are actually unused.
Most valid error = ... are just aliases for pywintypes.error, so I could transform error = "SomeModule error into error = pywintypes.error.
Of the 4 listed above, I don't see how any of them could reasonably be a pythoncom.error - what would the HRESULT be?
I noticed a few more
Sorry, I only looked at those 4 quoted above.
I meant pywintypes.error 🤦 Anyway, PRs incoming, starting with the tests.