GeezerVison

test_range seems to leak references. Using test.bisect_cmd gives me test.test_range.RangeTest.test_invalid_invocation as the relevant test.

➜  cpython git:(pr_13930) ./python.exe -m test -R 3:3 test_range
Run tests sequentially
0:00:00 load avg: 1.75 [1/1] test_range
beginning 6 repetitions
123456
......
test_range leaked [11, 11, 11] references, sum=33
test_range failed

== Tests result: FAILURE ==

1 test failed:
    test_range

Total duration: 19 sec 722 ms
Tests result: FAILURE

CC @vstinner because this PR actually affects the stable ABI for PyTypeObject (unlike #13858 where this was erroneously claimed)

Do you have an idea why this speeds up those calls that much? I'm just wondering if we could instead try to optimize the existing code path instead of implementing a mostly duplicate code path.

What are your plans for inheritance of tp_vectorcall? That should be clarified and documented.

Since dict() and dict.update() are very similar (basically, dict(*args, **kwargs) starts from an empty dict and then calls update(*args, **kwargs) on it), we should handle them together. I suggest to take that change out of this PR.

dict and dict.update are different.
dict(d1, **d2) is well known idiom to merge two dicts. While there is {**d1, **d2} now, many people are familiar with old idiom.

@methane, I don't understand which point you are trying to make.

Right now, there is a common implementation of dict() and dict.update() using VARARGS. I would like to change that to a common implementation of dict() and dict.update() using FASTCALL. Do you agree?

I opened https://bugs.python.org/issue37540 for the issue of checking that keyword names are strings.

I created #14588 and #14682 to separate two pieces from this PR. May I suggest again to merge those first? That would allow simplifying this PR and allowing to move forward with other PRs depending on #14588 and #14682.

It would make sense to delegate tp_call for range() and list() to vectorcall, rather than duplicating the implementations.

This PR has 4 relatively independent parts, and all of it seems stuck on one of them. I opened #18464 to get range() out of the way.

This PR was splitted into multiple smaller PRs which all are now all merged: see https://bugs.python.org/issue37207