gh-116646: Remove _PyLong_FileDescriptor_Converter()

[vstinner]

Argument Clinic now calls directly PyObject_AsFileDescriptor() for the "fildes" format.

Add tests on the "fildes" format in _testclinic_limited.

• Issue: C API: Add PyLong_FileDescriptor_Converter(): make private _PyLong_FileDescriptor_Converter() public #116646

[vstinner]

This change makes the "fildes" format compatible with the limited C API.

I don't think that anyone used _PyLong_FileDescriptor_Converter(), since only Argument Clinic generated code using it. See my code search: #116646 (comment)

[vstinner]

@erlend-aasland: Would you mind to review this PR?

[vstinner]

See also PR #116753

[serhiy-storchaka]

The converter is used if for some reasons the parsing code cannot be inlined and the PyArg_Parse* API is used. It includes the --limited option. So while _PyLong_FileDescriptor_Converter is not in the limited C API, it can be used when Argument Clinic generates the code for the limited C API. Even if it is not the case for current code, it may be necessary with other combinations of function calling options and parameter types.

[vstinner]

cc @serhiy-storchaka

[vstinner]

cc @serhiy-storchaka

Oops, I sent a ping, and just after posting it, I saw that you already replied!

@serhiy-storchaka:

The converter is used if for some reasons the parsing code cannot be inlined and the PyArg_Parse* API is used. It includes the --limited option.

I didn't know that. Do you have examples of cases when AC cannot inline code?

Maybe we should treat these cases as "not implemented" and issue an error, rather than always having to maintain two code paths to parse arguments. It's always possible to workaround these "not supported" cases by declaring all arguments as "object" and parse arguments inside the function.

[vstinner]

Apparently, my PR doesn't work as expected. I wrote a simpler PR: #116769

[serhiy-storchaka]

The principle is that inlining the parsing code and using faster calling conventions is an optimization, and that Argument Clinic should work independently from optimization. In worst case it should produce less optimal code, but not fail.

Do you have examples of cases when AC cannot inline code?

• The converter for which parse_arg() was not implemented. For example HANDLE in _winapi.c or pid_t in posixmodule.c.
• Optional groups. Many functions in _cursesmodule.c, but not only.
• If Py_LIMITED_API is defined.

[vstinner]

The converter for which parse_arg() was not implemented. For example HANDLE in _winapi.c or pid_t in posixmodule.c.

Ok, I see. Maybe we can add support for these types directly to AC.

Optional groups. Many functions in _cursesmodule.c, but not only.

That's a corner case. I don't think that we should support any type in optional groups.

If Py_LIMITED_API is defined.

We may try to write a limited C API implementation. But ok, now I understand better the problem.

Thanks a lot for your explanation!

---

For now, I wrote a way simpler PR which avoids these issues: PR gh-116769.