-
-
Notifications
You must be signed in to change notification settings - Fork 29.9k
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
ctypes defines global symbols #47352
Comments
ctypes defines a number of global symbols which aren't It would be good if these symbols either are changed to static, or get a |
Is it too late to fix this for Python 2.6 and Python 3.0? |
Formally, I can't answer that question; you need to ask the RM. Informally, I think only serious bugs can be fixed now; this bug is not |
These are the symbols on the trunk (20090328). There are *very* general module_methods probably could be static. AllocFunctionCallback Note there's a patch to get rid of FreeClosure: |
I think simple renaming would be fine. I do not see how module_methods could be made static; however, the Some other symbols could be made static because they are only used in a For MallocClosure/FreeClosure and the fedoraproject patch: Where does |
Here is a quite large patch (300 lines) against svn trunk that renames a theller@tubu32: doko, loewis, what do you think? |
Looks fine to me, except that I wouldn't call things "My*" (but I do |
Correction: The patch has 3000 lines, not 300. And I think that the 'My_Unicode_...' functions can be removed because |
Fixed in trunk (svn rev 71853). I'll leave this open until it is ported to py3k. |
BTW: The 'My_Unicode...' symbols are gone, too. |
svn rev 71845, in py3k branch. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: