Brett: > But otherwise I think we are making assumptions here. For me, unless we are trying to trim the C API down to just what is syntactically supported in Python and in such a way that it hides all C-level details I feel like we are guessing at what's best for other VMs, both today and in the future, until they can tell us that e.g. tuple indexing is actually not a problem performance-wise. The current API of PyTuple_GET_ITEM() allows to write: PyObject **items = &PyTuple_GET_ITEM(tuple, 0); to access PyTupleObject.ob_item. Not only it's possible, but it's used commonly in the CPython code base. Last week I replaced &PyTuple_GET_ITEM() pattern with a new _PyTuple_ITEMS() macro which is private. To be able to return PyObject**, you have to convert the full tuple into PyObject* objects which is inefficient if your VM uses something different (again, PyPy doesn't use PyObject* at all). More generally, I like to use PyTuple_GET_ITEM() example, just because it's easy to understand this macro. But it's maybe not a good example :-) Victor
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4