-
-
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
[C API] Private functions used by mypyc #121489
Comments
You can call something like: PyObject *empty = PyBytes_FromString("");
PyObject *res = PyObject_CallMethod(empty, "join", ...);
Py_DECREF(empty);
We are trying to get rid of _Py_IDENTIFIER() API. You should use your own mecanism for constant strings. You can call
For this one, I don't know. You might reimplement it, use the internal C API, or we should expose it as a public C API.
You can use PyUnicode_Compare(). Maybe we should expose it.
Would you mind to elaborate your use case? Can you use the new https://docs.python.org/dev/c-api/unicode.html#pyunicodewriter API instead? |
It's used here https://github.com/python/mypy/blob/4e3346ee1dee83868adc2411c4a0f4050cf2f95a/mypyc/lib-rt/str_ops.c#L120 in a function which basically reimplements |
IMO PyUnicodeWriter would be a good fit for this function, especially if you can compute the exact output string length in advance. |
I created issue gh-121645: [C API] Add PyBytes_Join() function. |
(cherry picked from commit aef95eb) Co-authored-by: Marc Mueller <30130371+cdce8p@users.noreply.github.com>
|
@cdce8p: Python 3.13rc1 has been released. What's the mypyc status? Which functions do you still need? |
I believe we've now resolved all issues here. There is one open PR on the mypy side which needs to get merged but that should be it python/mypy#17526.
Not strictly related to this issue. There are still two test issues with mypyc before we can support
|
The problem is that mimalloc is included inside extern "C" { ... }. Ah, another issue was already created: issue gh-122584. |
Please open a separated issue for that. |
|
@cdce8p: Can you close the issue? Or are there still issues not tracked by other open issues? |
Yes. Thanks again for your help! |

Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.

I've been working on adding support for
3.13to mypyc. After updating the codebase, there are still some functions left we depend on which are now private after #106320. Would it make sense to export these again? That would make adopting3.13a bit easier. /CC @vstinner_PyBytes_Joindefined inpycore_bytesobject.h_PyObject_CallMethodIdObjArgsdefined inpycore_call.h_PyType_CalculateMetaclassdefined inpycore_object.h_PyUnicode_EQdefined inpycore_unicodeobject.h_PyUnicode_FastCopyCharactersdefined inpycore_unicodeobject.h(this could be replaced withPyUnicode_CopyCharactersbut it's used in a simplified copy of_PyUnicode_JoinArraywhich also uses_PyUnicode_FastCopyCharacters).Other functions include these two. However, as they are inlined, it isn't a problem to include them.
_PyObject_CallMethodIdNoArgsand_PyObject_CallMethodIdOneArgdefined inpycore_call.hIt would be fine to keep all of them in
internal/pycore_*and just addPyAPI_FUNC./CC @hauntsaninja
Linked PRs
The text was updated successfully, but these errors were encountered: