Andy Lester <a...@petdance.com> added the comment:
> Would you mind to explain how it's an issue to modify PyObject* temporarily > during a function call? It's not a problem to modify the PyObject* during a function call. However, many functions don't need to modify the object, but are still taking non-const PyObject* arguments. For example if I have this code: if (Py_TYPE(deque) == &deque_type) { That doesn't modify deque to check the type, but because Py_TYPE casts away the constness, deque can't be a const object. However, with the new Py_IS_TYPE function: if (Py_IS_TYPE(deque, &deque_type)) { and these two changes: -static inline int _Py_IS_TYPE(PyObject *ob, PyTypeObject *type) { +static inline int _Py_IS_TYPE(const PyObject *ob, const PyTypeObject *type) { return ob->ob_type == type; } -#define Py_IS_TYPE(ob, type) _Py_IS_TYPE(_PyObject_CAST(ob), type) +#define Py_IS_TYPE(ob, type) _Py_IS_TYPE(((const PyObject*)(ob)), type) the deque variable can be const. Another example of a common pattern that I believe could benefit from this is Py_TYPE(ob)->tp_name. That could be turned into Py_TYPE_NAME(ob) and that would allow the ob to be a const pointer. If we can keep functions that don't modify the object to accept const PyObject* it will help make things safer in the long run. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue39573> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com