-
-
Notifications
You must be signed in to change notification settings - Fork 31.1k
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
gh-108314: Add PyDict_ContainsString() function #108323
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM except one minor comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CPython itself does not need this function, because _Py_ID()
is used everywhere. But for third-party code it should come in handy.
@@ -73,7 +82,7 @@ Dictionary Objects | |||
.. index:: single: PyUnicode_FromString() | |||
|
|||
Insert *val* into the dictionary *p* using *key* as a key. *key* should | |||
be a :c:expr:`const char*`. The key object is created using | |||
be a :c:expr:`const char*` UTF-8 encoded bytes string. The key object is created using |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be nice to backport such docs changes. Could you create a separate PR for this to make backporting easier? There may be other functions with const char *
parameters without explicitly specified encoding.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Once this PR is merged, I will extract the doc change into a separated PR to backport these doc changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I created PR #108448 for the doc changes.
As in #100100, I still don't think this function is worth it. Not every two-liner (well, five-liner in C) needs to be exposed as API. |
I think it is worth it, because attractive alternatives |
Can we at least not add to the stable ABI, at least until we have a clearer idea of where the C API is going? |
* The new function is not part of the limited C API. * Use PyDict_ContainsString() in pylifecycle.c and pythonrun.c.
b142bf9
to
4916d67
Compare
I updated my PR:
|
Sadly yes, CPython has a bias: because CPython has nice tools like Argument Clinic and _Py_ID(), we are less exposed to the annoyance/limitation of the C API. I hesitated to just use _Py_ID() in the 3 functions that I modified to use PyDict_ContainsString(), but these code paths are not performance critical and I was surprised that there was a "gap" in the API. I was trying to replace _PyDict_GetItemStringWithError() with PyDict_GetItemStringRef() and I saw that PyDict_GetItemStringRef() also has its annoyance for such code path, since it requires adding Py_DECREF(). |
Removing private functions from the public C API (issue #106320) is a way to discover gaps in the public C API. I also think that we should try to restrict ourselves to the public C API (or even the limited C API) in some/most C extensions of the stdlib to discover such issues, and complete the C API if needed. Private functions like _PyImport_GetModuleAttr() and _PyImport_GetModuleAttrString() are easy to reimplement: it's just PyImport_ImportModule() + PyObject_GetAttr() (and + PyUnicode_FromString() for the String variant), but it's annoying to maintain your own implementation. Where is the limit between "useful recipe of 5-10 lines" and "a public documented and tested API"? I suppose that it should be discussed on a case by case basis. |
test_ssl failed on macOS with:
|
I prepared a PR to add the function to pythoncapi-compat: python/pythoncapi-compat#71 |
If we go with Mark's proposal of splitting things into a stable, performant, minimal set of “ABI” functions and an ergonomic C API that calls them, these kinds of helpers should go in the latter only. But will we go with some variation of that proposal? Hopefully we'll have a better idea in a few months :) |
@methane @serhiy-storchaka @encukou: I updated my PR, it's no longer part of the limited C API. So what do you think? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
|
Use PyDict_ContainsString() in pylifecycle.c and pythonrun.c.
📚 Documentation preview 📚: https://cpython-previews--108323.org.readthedocs.build/