Add PyObject_CallOneArg()

[jdemeyer]

BPO	37483
Nosy	@vstinner, @methane, @skrah, @jdemeyer, @corona10, @miss-islington
PRs	bpo-37483: add _PyObject_CallOneArg() function #14558 bpo-37493: use _PyObject_CallNoArg in more places #14575 bpo-37483: fix refleak #14599 bpo-37483: fix reference leak in _PyCodec_Lookup #14600 bpo-37483: Add PyObject_CallOneArg() in the What's New in Python 3.9 #23062 [3.9] bpo-37483: Add PyObject_CallOneArg() in the What's New in Python 3.9 (GH-23062) #23074

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2020-11-01.13:28:37.261>
created_at = <Date 2019-07-02.12:14:43.792>
labels = ['interpreter-core', '3.9', 'performance']
title = 'Add PyObject_CallOneArg()'
updated_at = <Date 2020-11-01.13:28:37.261>
user = 'https://github.com/jdemeyer'

bugs.python.org fields:

activity = <Date 2020-11-01.13:28:37.261>
actor = 'corona10'
assignee = 'none'
closed = True
closed_date = <Date 2020-11-01.13:28:37.261>
closer = 'corona10'
components = ['Interpreter Core']
creation = <Date 2019-07-02.12:14:43.792>
creator = 'jdemeyer'
dependencies = []
files = []
hgrepos = []
issue_num = 37483
keywords = ['patch']
message_count = 32.0
messages = ['347138', '347172', '347181', '347196', '347197', '347198', '347200', '347202', '347203', '347205', '347206', '347208', '347209', '347210', '347211', '347213', '347214', '347216', '347217', '347220', '347222', '347224', '347231', '347267', '347318', '347330', '347332', '347333', '347335', '370685', '380132', '380133']
nosy_count = 6.0
nosy_names = ['vstinner', 'methane', 'skrah', 'jdemeyer', 'corona10', 'miss-islington']
pr_nums = ['14558', '14575', '14599', '14600', '23062', '23074']
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'performance'
url = 'https://bugs.python.org/issue37483'
versions = ['Python 3.9']

[jdemeyer]

As discussed in https://mail.python.org/archives/list/capi-sig@python.org/thread/X6HJOEX6RRFLNKAQSQR6HLD7K4QZ4OTZ/ it would be convenient to have a function PyObject_CallOneArg() for making calls with exactly 1 positional argument and no keyword arguments. Such calls are very common. This would be analogous to PyObject_CallNoArgs().

[methane]

What do you think about macro like this?

  #define _PyObject_CALL_WITH_ARGS(func, ...) \
      _PyObject_Vectorcall(func, (PyObject*[]){NULL, __VA_ARGS__} + 1, \
              sizeof((PyObject*[]){__VA_ARGS__})/sizeof(PyObject*) | PY_VECTORCALL_ARGUMENTS_OFFSET, \
              NULL)

Pros: it can be used for 2 or 3 arguments too.
Cons: readability...

[jdemeyer]

Variadic macros are not part of C89, so that would require changing PEP-7.

[jdemeyer]

Cons: readability...

It's a single relatively short macro. I'm not worried about that. I'm more about compiler support for such macros. I'll make a PR with this idea and see what CI says.

[vstinner]

Variadic macros are not part of C89, so that would require changing PEP-7.

PEP-7 uses C99 since Python 3.6:
https://www.python.org/dev/peps/pep-0007/#c-dialect

What do you think about macro like this?

Macros cannot be used in all C extensions. For the PEP-587, I was asked to replace macros with functions.

I would prefer a PyObject_CallOneArg() function than yet another ugly and dangerous macro. Sometimes, a regular function is better for stack consumption: it doesn't increase the stack consumption in the call site, stack memory is "released" once PyObject_CallOneArg() exit. In the past, I had to disable inlining in some functions to reduce the stack consumption. (I'm not sure if this optimization is still around.)

[methane]

AFAIK, gcc, clang, and MSVC support it.

Another cons is, general pitfall of macro:

_PyObject_CALL_WITH_ARGS(func, PyDict_GetItem(d, key)); // PyDict_GetItem(d, key) is called twice.

If two or more arguments are not common, I prefer _PyObject_CallOneArg to macro.

[jdemeyer]

_PyObject_CALL_WITH_ARGS(func, PyDict_GetItem(d, key)); // PyDict_GetItem(d, key) is called twice.

That's pretty bad and in my opinion a good reason to reject this idea.

If two or more arguments are not common, I prefer _PyObject_CallOneArg to macro.

I posted some counts at https://mail.python.org/archives/list/capi-sig@python.org/message/3I76R27YMFSKB5JQIM3E4NA3BECVTZHP/

[jdemeyer]

_PyObject_CALL_WITH_ARGS(func, PyDict_GetItem(d, key)); // PyDict_GetItem(d, key) is called twice.

Actually, it's not a problem: sizeof() is special, it only looks at the type of its argument, it doesn't execute the code.

[jdemeyer]

PEP-7 uses C99 since Python 3.6: https://www.python.org/dev/peps/pep-0007/#c-dialect

That's not what the PEP says: "Python versions greater than or equal to 3.6 use C89 with several select C99 features"

"several select C99 features" is not the same of using C99.

Plus, I'm also worried about C++. We also support compiling C++ extensions with the same header files, so it must be C++ compatible also.

[methane]

Macros cannot be used in all C extensions. For the PEP-587, I was asked to replace macros with functions.

This is just an helper inline function / macro to ease calling _PyObject_Vectorcall.
Extensions can port this helper inline function / macro to ease calling _PyObject_Vectorcall.

I don't want to make this non-inline function.

[skrah]

The motivation for this PR is "it would be convenient to have this function".

This is probably true, but generally I would not change 47 files at once.

Most of the locations are probably not performance sensitive.

[methane]

This change doesn't make caller code complicated. It makes caller little simpler.

Choosing performance sensitive code is much hard than replace all occurrences.
So I'm OK to change all callers except code owner opposed at once.