[issue46140] Some API methods could take const Py_buffer* instead of Py_buffer *
Change by David Hewitt : -- keywords: +patch pull_requests: +28438 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30217 ___ Python tracker <https://bugs.python.org/issue46140> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46140] Some API methods could take const Py_buffer* instead of Py_buffer *
New submission from David Hewitt : The limited api methods `PyBuffer_GetPointer`, `PyBuffer_FromContiguous`, `PyBuffer_ToContiguous` and `PyMemoryView_FromBuffer` take buffer arguments as `Py_buffer *`. They do not mutate the buffer info, so could simply take `const Py_buffer *`. There is already precedent to take `const Py_buffer *` argument in `PyBuffer_IsContiguous`. I'm going to submit a PR to fix. -- messages: 408976 nosy: davidhewitt priority: normal severity: normal status: open title: Some API methods could take const Py_buffer* instead of Py_buffer * versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46140> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42415] python3.lib in Python3.9.0 Windows distribution does not contain PyObject_CallNoArgs symbol
New submission from David Hewitt : I'm unsure if this is a packaging error or a misunderstanding by me. I'm trying to link a binary on windows with Py_LIMITED_API set. According to https://www.python.org/dev/peps/pep-0384/#linkage I _think_ I'm supposed to be linking against python3.lib (instead of python39.lib). However my build fails because the PyObject_CallNoArgs symbol is not present in python3.lib I see that the symbol is indeed present in python39.lib Is this a misunderstanding on my part? I was under the impression that python3.lib will only contain symbols available in the limited api, and that (since 3.9) PyObject_CallNoArgs is part of the limited api. -- components: Windows messages: 381458 nosy: David Hewitt, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: python3.lib in Python3.9.0 Windows distribution does not contain PyObject_CallNoArgs symbol type: compile error versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue42415> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39773] Export symbols for vectorcall
David Hewitt added the comment: I had suspected that might be the case. We already use PyObject_Call but had been hoping to experiment with the Vectorcall optimizations. Without the symbols I might resort to reproducing the implementation of these functions on the Rust side. Shouldn't be too much code duplication. -- resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue39773> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39773] Export symbols for vectorcall
New submission from David Hewitt : I have been looking into using vectorcall in [pyo3](https://github.com/PyO3/pyo3) (Rust bindings to Python) against python3.8. It looks like the _PyObject_Vectorcall symbols are not included in the shared library. I've checked both Windows and Linux. I think the `static inline` definition of `PyObject_Vectorcall` and related functions in `abstract.h` means that they won't be exported as symbols in the final library? -- messages: 362789 nosy: David Hewitt priority: normal severity: normal status: open title: Export symbols for vectorcall versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue39773> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
