-
-
Notifications
You must be signed in to change notification settings - Fork 97
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
'SyntaxError: invalid syntax' occurs during MS Project module generation with GetModule function #524
Comments
Yes, indeed, it is expected behavior that classes are imported in "the second import". |
This is the same issue that's happening with #517. What's puzzling is the situation in which this problem occurs. Please share the codebase of When this problem is reproduced, the approach that can be taken should differ depending on which of the following is happening:
The import part of the friendly module generated by comtypes/comtypes/tools/codegenerator.py Lines 622 to 640 in 7fa88e1
If there is something that makes the length of this set zero, problematic codebase will be generated. However, at the moment, nothing comes to mind that would cause the length of this set to be zero. Help from the community is also welcome. |
Can you please try to reproduce this issue by the steps below. Precondition: comtypes version is 1.4.0 Steps to reproduce:
NOTE: you may need to perform the steps above several times to reproduce. Actual result:
|
I encountered the same error in my environment. Upon checking the source code and going to the definition, it seems that the cause is that the name Such COM type libraries were overlooked when implementing this feature. I think the way to deal with this kind of problem is to assign numerical literals directly, rather than referring to the values of enumeration members from |
I have made changes to numerical literals to be members of the enumeration.
Please install it in your environment and give it a try. |
From #524 (comment),
I am also waiting for information on this matter. |
Attached the |
I've looked at the code generated in your environment, and it seems that there are no elements in the codebase of the wrapper module itself that would cause a
Please share the results about this as well. Also, when sharing such a codebase, it would be helpful if you could upload it to your public repository and let us know the permalink, because attached files can't be checked immediately and GitHub's syntax highlight can't be used. |
There has been a comment about comtypes/comtypes/tools/tlbparser.py Lines 721 to 723 in 7fa88e1
In your case, it’s not that the Therefore, it seems that the compatibility between |
Those changes helps. |
The cause of this comtypes/comtypes/client/_generate.py Lines 193 to 203 in 7fa88e1
comtypes/comtypes/client/_generate.py Lines 205 to 222 in 7fa88e1
comtypes/comtypes/client/_generate.py Lines 224 to 246 in 7fa88e1
I think this is similar to issue #114 in terms of the event and cause. If Python terminates after the wrapper module is generated by calling By determining if the wrapper module already exists and the friendly module does not, and displaying an appropriate error message, we can help users understand what to do next to resolve the error. Also, by not generating the wrapper module file until the friendly module file is generated, and making them both files at the same time when they are ready, I think we can reduce the occurrence of this error. |
Thank you. I’m planning to apply a patch to at least resolve the I would like a little more time to respond to the |
I've got both modules present when this issue occurs. |
Please keep the Let us know the result. |
In this case we still get the error and |
The same thing happened in my environment. |
I noticed that the condition for whether the This is the same kind of thing that I discussed in #116 (comment). Recreating both the wrapper module and the friendly module unless both modules already exist might make it less producing such partial files. In the current implementation, the wrapper module file is generated, then the codebase for the friendly module is generated, and then the friendly module file is generated. By generating both the codebase for the wrapper module and the codebase for the friendly module, and then generating the module files for both, the time between generating the two files can be reduced, which could increase stability. |
Based on the considerations I made in #524 (comment), I changed the implementation of
Please install this in your environment, try the following, and let us know the result:
Thank you. |
In addition to the branch mentioned earlier, I would like you to This branch is the one that has merged the contents of #527, #528, and #529 into |
I executed the contents of
I confirmed that even if either the wrapper module or the friendly module file existed, both files and modules would be regenerated. Testing this requires diving into Python's import system, which is difficult. However, even with this implementation, all the existing unit tests were able to run and they all passed. In early May, I plan to merge this content and release it as Any opinions would be appreciated. |
MS_PROJECT_HASH = '{A7107640-94DF-1068-855E-00DD01075445}'
com.GetModule((MS_PROJECT_HASH, 4, 0)) returns 'SyntaxError: invalid syntax' starting from 1.4.0 version:
File "C:\Python39\lib\site-packages\comtypes\gen\MSHTML.py", line 4 from comtypes.gen._3050F1C5_98B5_11CF_BB82_00AA00BDCE0B_0_4_0 import ^ SyntaxError: invalid syntax
Current issue is reproducible periodically.
Sometimes it happens to import appropriate classes but is it expected to have the second import?
The text was updated successfully, but these errors were encountered: