Skip to content
Merged
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Apply suggestions from code review: move News entry, move PyCMethod_C…
…heck*() macros out of the limited API.
  • Loading branch information
scoder committed May 12, 2020
commit 8795b9f45b41f5bfffc2855155d0a0e919c6f86c
3 changes: 3 additions & 0 deletions Include/cpython/methodobject.h
Original file line number Diff line number Diff line change
Expand Up @@ -4,6 +4,9 @@

PyAPI_DATA(PyTypeObject) PyCMethod_Type;

#define PyCMethod_CheckExact(op) Py_IS_TYPE(op, &PyCMethod_Type)
#define PyCMethod_Check(op) PyObject_TypeCheck(op, &PyCMethod_Type)

/* Macros for direct access to these values. Type checks are *not*
done, so use with care. */
#define PyCFunction_GET_FUNCTION(func) \
Expand Down
3 changes: 0 additions & 3 deletions Include/methodobject.h
Original file line number Diff line number Diff line change
Expand Up @@ -16,9 +16,6 @@ PyAPI_DATA(PyTypeObject) PyCFunction_Type;
#define PyCFunction_CheckExact(op) Py_IS_TYPE(op, &PyCFunction_Type)
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would prefer to exclude PyCFunction_CheckExact() from the limited C API.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not so sure. We are changing the semantics of PyCFunction_Check() by adding a subtype that it covers. The macro is a part of the limited C-API and thus, the semantic change is a problem all by itself. Either we accept that, then we should add the "obvious" related CheckExact macro, also to the limited API. Or, we reject that change all together. I don't think the latter is an option, though.

Personally, I'd say, since it's a macro, it doesn't hurt, since it has no impact at all on the ABI. Everyone can safely copy and use that macro also on their side, so why not just add it?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will not hold this PR just for that. We can should PyCFunction_CheckExact() as it is in Python 3.9, and revisit the issue later. I created https://bugs.python.org/issue40601 to explain my concern: I plan to work on that in Python 3.10, it's too late for Python 3.9.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do note that PyCMethod is a bit of a hack in that PyCFunction is still not an "acceptable base type". You can't subclasstype(print), but static types happen to bypass the Py_TPFLAGS_BASETYPE check. This is one more thing to be resolved if we want all types can become heap types.

#define PyCFunction_Check(op) PyObject_TypeCheck(op, &PyCFunction_Type)

#define PyCMethod_CheckExact(op) Py_IS_TYPE(op, &PyCMethod_Type)
#define PyCMethod_Check(op) PyObject_TypeCheck(op, &PyCMethod_Type)

typedef PyObject *(*PyCFunction)(PyObject *, PyObject *);
typedef PyObject *(*_PyCFunctionFast) (PyObject *, PyObject *const *, Py_ssize_t);
typedef PyObject *(*PyCFunctionWithKeywords)(PyObject *, PyObject *,
Expand Down