gh-108314: Add PyDict_ContainsString() function#108323
Conversation
methane
left a comment
There was a problem hiding this comment.
LGTM except one minor comment.
serhiy-storchaka
left a comment
There was a problem hiding this comment.
CPython itself does not need this function, because _Py_ID() is used everywhere. But for third-party code it should come in handy.
|
|
||
| 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.
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.
Once this PR is merged, I will extract the doc change into a separated PR to backport these 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? |
|
Use PyDict_ContainsString() in pylifecycle.c and pythonrun.c.
📚 Documentation preview 📚: https://cpython-previews--108323.org.readthedocs.build/