-
Notifications
You must be signed in to change notification settings - Fork 6
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
Non-namespaced identifiers #46
Comments
All of this can be solved incrementally, right? Just slap a |
I don't think we should rename Automation to catch mistakes might help. |
(Somewhat related: Qt infamously breaks Python API by defining the macro |
I was always annoyed that the structure is not simply called Why is the structure of the PyInterpreterState called... In practice, the structure name are never used. So we can just fix them, no? |
That's a hard problem since most names are generated by configure, and changing configure is not easy. Maybe Python.h should not include |
Maybe we can introduce new For example, it's common to have to cast a function to |
We can easily define autoconf macros that wrap |
So maybe just create a cpython issue + PR for this (linking back here)? |
Thanks for the ping. Yes, it's on my list; I just haven't found the time to do it yet. I'll create the issue right away, though. UPDATE: I created python/cpython#105813 |
See my comment #43 (comment) about E_EOF constant of errcode.h which is used by public |
Proposed guideline issue: capi-workgroup/api-evolution#21 |
Having pyconfig.h as part of the public API is questionable in the first place (both as a header and through sysconfig). Adding and removing definitions from pyconfig.h is technically an API change and that means that adding a new configure check in a bug fix release can be dodgy. |
The problem is that Python.h requires these HAVE macros.
I removed I'm fine with adding But to remove
The difference is to give users the ability to decide when and how they are affected by these changes. Previously, I pushed changes to affect everybody, and sometimes it went bad, it affected too many users and pushed against it and ask for revert. The reason for revert is basically that "too many changes" occurred at the same time, and that they were busy with other duties. |
I agree with the need for a clean migration path, but this repo is for listing problems and not solutions 😉. There's bound to be extensions that break when we'd remove or rename the macro's in
Only if we decide that this is the right long term solution. It might be better to switch to private or unstable names ( Not for here, but the same issue is present in |
This project was created to write PEP 733 – An Evaluation of Python’s Public C API. The PEP is now written. Maybe it's time to convert these "problems" into solutions, and close these problems issues? |
I wouldn't close until there's at least a plan to solve them. |
The headers define a number of identifiers that don't start with
Py
(or_Py
), potentially clashing with other code.destructor
orsetter
METH_VARARGS
struct _object
HAVE_STRFTIME
orSIZEOF_SIZE_T
Relatedly, header names should probably also be namespaced (or hidden in a subdirectory, expecially if users aren't supposed to include them directly)
The text was updated successfully, but these errors were encountered: