Three extension modules: _testcapimodule.c, posixmodule.c, and mathmodule.c are using `_PyObject_LookupSpecial` which is not API.

These should instead use `PyObject_GetAttrString`, `PyType_GetSlot`.

Correction, this is not as trivial as just using `PyObject_GetAttrString`. Will investigate the correct behavior.

Batteries-included extension modules aren't limited to the public and/or limited API; they use tons of undocumented internal APIs (everything to do with Py_IDENTIFIERs being an obvious and frequently used non-public API).

_PyObject_LookupSpecial is necessary to lookup special methods on the class of an instance (bypassing the instance itself) when no C level slot is associated with the special method (e.g. the math module using it to look up __ceil__ to implement math.ceil). Sure, each of these modules could reimplement it from scratch, but I'm not seeing the point in doing so.

> Three extension modules: _testcapimodule.c, posixmodule.c, and mathmodule.c are using `_PyObject_LookupSpecial` which is not API.

I don't understand the issue that you are trying to solve. Yes, Python builtin extensions use private functions of the C API.

@vstinner: Sorry for not being clear - The intention of this change is two-fold:
1) Simplify the implementation of these functions.
2) Reduce the surface area of the C-API.

Given that the same functionality can be achieved with public functions of the C-API. This is a nice cleanup over the current approach.

I also fixed the title to properly reflect what this is trying to achieve.

There is nothing wrong with using private C API in the implementation of standard CPython extensions. This API was designed for this.

In contrary, there are problems with your code:

* It is less efficient. String objects are created and destroyed twice per every function call, in PyObject_HasAttrString() and in PyObject_CallMethod(). Format string is parsed in PyObject_CallMethod(). Other temporary objects are created and destroyed.

* It uses inherently broken PyObject_HasAttrString(). PyObject_HasAttrString() swallows exceptions (for example a MemoryError raised when create a temporary string object) and can return an incorrect result.

* It is not equivalent with the existing code. For example it does not work properly if the dunder method is a static method.

Agreed with everything in Serhiy's comments. This patch disregards why _PyObject_LookupSpecial and the various _Py_IDENTIFIER related stuff was created in the first place (to handle a non-trivial task efficiently/correctly) in favor of trying to avoid C-APIs that are explicitly okay to use for the CPython standard extensions. The goal is a mistake in the first place; no patch fix will make the goal correct.

Closing as not a bug.