PEP 590: Base update

[encukou]

The discussion on GH-1028 got out of hand.
This PR attempts to collect the "uncontroversial" changes, and also to collect the unresolved issues.

If there's something here you don't agree with, point it out.
I'll add it to the following list of things to hash out (and, if feasible, revert the change here).

Please don't discuss any of these in this PR.

cc @markshannon @jdemeyer

The vectorcall function's kwname argument:

• PyTupleObject or PyObject?
• Can be NULL?
• Can the tuple be empty?

vectorcall → vectorcallfunc

I'm not sure this was settled.

tp_vectorcall_offset type

• uintptr_t (original)
• Py_ssize_t (matches type of offsetof and existing practice)
• ptrdiff_t (actual "difference of pointers" type)

This is probalby pointless bikeshedding.

METH_VECTORCALL function type

• PyObject *(*call) (PyObject *self, PyObject *const *args, Py_ssize_t nargs, PyObject *kwname)
• vectorcallfunc

(There is a discussion on what code is "trusted".)

PyCall_MakeVectorCall name

• PyCall_MakeVectorcall (original)
• PyCall_Vectorcall
• PyVectorcall_Call

PyVectorcall_Function

Do we need this one?

- ``vectorcallfunc PyVectorcall_Function(PyObject *obj)``: If ``obj`` does not support vectorcall,
  return ``NULL``.
  Otherwise, return the vectorcall pointer in the instance ``obj`` (which may be ``NULL``).

PyCall_MakeTpCall

Do we need to add this one back?

PY_VECTORCALL_ARGUMENTS_OFFSET vs. PY_VECTORCALL_PREPEND

Passing a dict to PyObject_Vectorcall

[encukou]

I checked with Mark on this. @jdemeyer, can we merge this and move forward with the individual points?

[markshannon]

One typo, otherwise LGTM.

[jdemeyer]

@jdemeyer, can we merge this and move forward with the individual points?

OK

[jdemeyer]

You mention bringing back PyCall_MakeTpCall but you don't actually do that.

[encukou]

The PR description lists the unresolved issues, not what this PR does. In retrospect, that's quite confusing. Sorry!

I'll kick off discussions on these issues on python-dev.