bpo-46921: Vectorcall support for `super()` by Fidget-Spinner · Pull Request #31687 · python/cpython

The current PR does not check the number of arguments.
Please add the unit test for this also :)

AS-IS

>>> super(int, int, int)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: super() takes at most 2 arguments (3 given)

PR

>>> super(int, int, int)
<super: <class 'int'>, NULL>

When you're done making the requested changes, leave the comment: I have made the requested changes; please review again.

@corona10 thanks for taking the time to benchmark this and for the extremely useful suggestions too. I forgot all the cool argument checking helpers we have since I'm a little rusty.

If you're interested, there's the monster GH-30992 too where I measured >2X speedup. But it's very complex and I don't have high hopes for it being merged.

I wonder how much a free list would help? I'd bet super objects typically have short lifetimes and not many are alive at once.

@Fidget-Spinner

Please add the unit test for this also :)

As I wrote, please add the test for checking TypeError when the given number of arguments are greater equal than 3 :)

@Fidget-Spinner

Please add the unit test for this also :)

As I wrote, please add the test for checking TypeError when the given number of arguments are greater equal than 3 :)

🤦 my bad, I missed that. Thanks again.

I added one more test since I noticed it wasn't covered in the test suite.

I wonder how much a free list would help? I'd bet super objects typically have short lifetimes and not many are alive at once.

There will probably be some improvement versus relying on CPython's obmalloc "free list". My final goal is to not need any super object at all though :). BTW, are you able to guesstimate how much more complexity we need for a super free list? If it isn't too complex, it's likely more worth it than my cached superinstruction overkill implementation.

I wonder how much a free list would help? I'd bet super objects typically have short lifetimes and not many are alive at once.

There will probably be some improvement versus relying on CPython's obmalloc "free list". My final goal is to not need any super object at all though :). BTW, are you able to guesstimate how much more complexity we need for a super free list? If it isn't too complex, it's likely more worth it than my cached superinstruction overkill implementation.

I think it's (relatively) straightforward, see floatobject.c for an example. The actual free list gets attached to _PyInterpreterState there.