Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is it OK to remove _PyObject_Vectorcall? #212

Closed
encukou opened this issue Oct 31, 2023 · 8 comments
Closed

Is it OK to remove _PyObject_Vectorcall? #212

encukou opened this issue Oct 31, 2023 · 8 comments

Comments

@encukou
Copy link
Member

encukou commented Oct 31, 2023

PEP-590 says:

The underscore in the names _PyObject_Vectorcall and _Py_TPFLAGS_HAVE_VECTORCALL indicates that this API may change in minor Python versions. When finalized (which is planned for Python 3.9), they will be renamed to PyObject_Vectorcall and Py_TPFLAGS_HAVE_VECTORCALL. The old underscore-prefixed names will remain available as aliases.

I'm not aware of a decision to override the PEP. But the reasoning behind the changes is scattered in a maze of issues, PRs and topics that were never collected into a PEP, so it's very possible that I'm missing something. (It seems @vstinner is in charge of the removals, but I don't know where to ask or discuss -- see e.g. here).

The question I want to ask is practically intractable at this point, so I'll ask a simple one instead:
Does the SC think that it is OK to remove _PyObject_Vectorcall without a change to PEP-590, new PEP, or SC decision?

@vstinner
Copy link
Member

When I removed these private functions, I wasn't aware that PEP 590 had a specific section about them.

Last June, I only found 8 projects using it: python/cpython#106084 (comment)

In the meanwhile, I added some vectorcall APIs for Python 3.8 in the pythoncapi-compat project: https://pythoncapi-compat.readthedocs.io/en/latest/api.html#c.PyObject_Vectorcall

@gpshead
Copy link
Member

gpshead commented Nov 6, 2023

I captured my personal thoughts on this theme in python/cpython#111481 (comment)

@gpshead
Copy link
Member

gpshead commented Nov 7, 2023

The SC has been chatting about the overall theme behind recent presumed-private C API removals and we're happy to see that the C API working group appears to be looking into the question per Guido on 106320.

@gvanrossum
Copy link
Member

Of course that would require there to be a C API WG, which is awaiting approval of PEP 731 (#210).

@encukou
Copy link
Member Author

encukou commented Nov 8, 2023

Right. There are strong personal opinions floating around, spanning the full range of "revert it all"–"moratorium"–"full steam ahead".

@brettcannon
Copy link
Member

Of course that would require there to be a C API WG, which is awaiting approval of PEP 731 (#210).

Correct, hence why it's actively being discussed by the SC.

@vstinner
Copy link
Member

Update: PEP 590 aliases kept for backward compatibility were restored in Python 3.13 by python/cpython#112115

@Yhg1s
Copy link
Member

Yhg1s commented Nov 20, 2023

Now that the C API WG PEP is accepted and this has been solved for 3.13 anyway, the SC is leaving this question for the WG.

@Yhg1s Yhg1s closed this as completed Nov 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants