[issue37483] Add PyObject_CallOneArg()

Change by Dong-hee Na : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___ ___

[issue37483] Add PyObject_CallOneArg()

miss-islington added the comment: New changeset 0312efcd2bb3d7964dbfe2b4cbd5f5b440aed049 by Miss Skeleton (bot) in branch '3.9': bpo-37483: Add PyObject_CallOneArg() in the What's New in Python 3.9 (GH-23062) https://github.com/python/cpython/commit/0312efcd2bb3d7964dbfe2b4cbd5f5b440aed049

[issue37483] Add PyObject_CallOneArg()

Change by miss-islington : -- nosy: +miss-islington nosy_count: 5.0 -> 6.0 pull_requests: +21994 pull_request: https://github.com/python/cpython/pull/23074 ___ Python tracker

[issue37483] Add PyObject_CallOneArg()

Dong-hee Na added the comment: New changeset 7feb54a6348f6220b2798686c812f110b53d by Dong-hee Na in branch 'master': bpo-37483: Add PyObject_CallOneArg() in the What's New in Python 3.9 (GH-23062) https://github.com/python/cpython/commit/7feb54a6348f6220b2798686c812f110b53d

[issue37483] Add PyObject_CallOneArg()

Change by Dong-hee Na : -- nosy: +corona10 nosy_count: 4.0 -> 5.0 pull_requests: +21981 stage: resolved -> patch review pull_request: https://github.com/python/cpython/pull/23062 ___ Python tracker

[issue37483] Add PyObject_CallOneArg()

STINNER Victor added the comment: Oh, PyObject_CallOneArg() is missing in the What's New in Python 3.9: https://docs.python.org/dev/whatsnew/3.9.html#id1 Can someone please propose a PR to add it? I reopen the issue. -- resolution: fixed -> status: closed -> open

[issue37483] Add PyObject_CallOneArg()

Change by Jeroen Demeyer : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue37483] Add PyObject_CallOneArg()

STINNER Victor added the comment: Thanks for the quick fix ;-) -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue37483] Add PyObject_CallOneArg()

Inada Naoki added the comment: New changeset 6e43d07324ca799118e805751a10a7eff71d5a04 by Inada Naoki (Jeroen Demeyer) in branch 'master': bpo-37483: fix reference leak in _PyCodec_Lookup (GH-14600) https://github.com/python/cpython/commit/6e43d07324ca799118e805751a10a7eff71d5a04 --

[issue37483] Add PyObject_CallOneArg()

Jeroen Demeyer added the comment: > Jeroen: hum, you both proposed a similar fix :-) It seems that I lost the race ;-) But seriously: if we both independently came up with the same solution, that's a good sign that the solution is correct. --

[issue37483] Add PyObject_CallOneArg()

STINNER Victor added the comment: INADA-san, Jeroen: hum, you both proposed a similar fix :-) One fix is enough. See my review on PR 14600. -- ___ Python tracker ___

[issue37483] Add PyObject_CallOneArg()

Change by Jeroen Demeyer : -- pull_requests: +14415 pull_request: https://github.com/python/cpython/pull/14600 ___ Python tracker ___

[issue37483] Add PyObject_CallOneArg()

Change by Inada Naoki : -- pull_requests: +14414 pull_request: https://github.com/python/cpython/pull/14599 ___ Python tracker ___

[issue37483] Add PyObject_CallOneArg()

STINNER Victor added the comment: The following commit introduced a reference leak: commit 196a530e00d88a138973bf9182e013937e293f97 Author: Jeroen Demeyer Date: Thu Jul 4 12:31:34 2019 +0200 bpo-37483: add _PyObject_CallOneArg() function (#14558) Example:

[issue37483] Add PyObject_CallOneArg()

Inada Naoki added the comment: New changeset 196a530e00d88a138973bf9182e013937e293f97 by Inada Naoki (Jeroen Demeyer) in branch 'master': bpo-37483: add _PyObject_CallOneArg() function (#14558) https://github.com/python/cpython/commit/196a530e00d88a138973bf9182e013937e293f97 --

[issue37483] Add PyObject_CallOneArg()

Change by Jeroen Demeyer : -- pull_requests: +14394 pull_request: https://github.com/python/cpython/pull/14575 ___ Python tracker ___

[issue37483] Add PyObject_CallOneArg()

Jeroen Demeyer added the comment: Test of stack usage: from _testcapi import stack_pointer class D(dict): def __missing__(self, key): sp = stack_pointer() print(f"stack usage = {TOP - sp}") return None d = D() TOP = stack_pointer() d[0] **before**: stack usage =

[issue37483] Add PyObject_CallOneArg()

Jeroen Demeyer added the comment: Victor, what's your opinion on adding PyObject_CallOneArg() to the limited API? -- ___ Python tracker ___

[issue37483] Add PyObject_CallOneArg()

Inada Naoki added the comment: I don't want to add many functions to limited/public APIs. Note that public APIs defined outside of cpython/ are considered mandatory for all Python implementations supporting Python/C API. When portability is more important than performance, there are many

[issue37483] Add PyObject_CallOneArg()

Jeroen Demeyer added the comment: Stefan: I used an underscore by analogy with PyObject_CallNoArgs()/_PyObject_CallNoArg(), where the first is in the limited API and the second is an inline function in the cpython API. But maybe we could revisit that decision. --

[issue37483] Add PyObject_CallOneArg()

Jeroen Demeyer added the comment: > Is there any benchmark showing if it's faster Here is one example: class D(dict): def __missing__(self, key): return None d = D() and now benchmark d[0] **before**: Mean +- std dev: 173 ns +- 1 ns **after**: Mean +- std dev: 162 ns +- 1 ns

[issue37483] Add PyObject_CallOneArg()

Stefan Krah added the comment: > Or do you care about *using* API with underscore? If so, I'm OK to stop > changing some callers which are not tightly coupled with Python. I care about this one. Indeed I think underscore functions should be used in strategic places inside the core

[issue37483] Add PyObject_CallOneArg()

Inada Naoki added the comment: > It adds yet another special case underscore function that one cannot use in > external projects. So I would not say that is simpler. I don't get what you mean. Do you care about *adding* API with underscore? If so, it doesn't make caller code complex. It

[issue37483] Add PyObject_CallOneArg()

STINNER Victor added the comment: > Exactly. I see no reason to prefer PyObject_CallFunctionObjArgs(func, arg, > NULL) over _PyObject_CallOneArg(func, arg) In this case, maybe the whole idea of _PyObject_CallOneArg() is not worth it? Is there any benchmark showing if it's faster or use less

[issue37483] Add PyObject_CallOneArg()

Jeroen Demeyer added the comment: > It adds yet another special case underscore function that one cannot use in > external projects. So I would not say that is simpler. If you're worried about the underscore, I will make a separate PR to add a non-underscored version, similar to

[issue37483] Add PyObject_CallOneArg()

Stefan Krah added the comment: It adds yet another special case underscore function that one cannot use in external projects. So I would not say that is simpler. Has there been any performance measurement at all? -- ___ Python tracker

[issue37483] Add PyObject_CallOneArg()

Jeroen Demeyer added the comment: Exactly. I see no reason to prefer PyObject_CallFunctionObjArgs(func, arg, NULL) over _PyObject_CallOneArg(func, arg) -- ___ Python tracker

[issue37483] Add PyObject_CallOneArg()

Inada Naoki added the comment: 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. --

[issue37483] Add PyObject_CallOneArg()

Stefan Krah added the comment: 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. -- nosy: +skrah

[issue37483] Add PyObject_CallOneArg()

Inada Naoki added the comment: > 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

[issue37483] Add PyObject_CallOneArg()

Jeroen Demeyer added the comment: > 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

[issue37483] Add PyObject_CallOneArg()

Jeroen Demeyer added the comment: > _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. --

[issue37483] Add PyObject_CallOneArg()

Jeroen Demeyer added the comment: > _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 >

[issue37483] Add PyObject_CallOneArg()

Inada Naoki added the comment: 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

[issue37483] Add PyObject_CallOneArg()

STINNER Victor added the comment: > 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

[issue37483] Add PyObject_CallOneArg()

Jeroen Demeyer added the comment: > 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. -- ___ Python tracker

[issue37483] Add PyObject_CallOneArg()

Jeroen Demeyer added the comment: Variadic macros are not part of C89, so that would require changing PEP 7. -- ___ Python tracker ___

[issue37483] Add PyObject_CallOneArg()

Inada Naoki added the comment: 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*) |

[issue37483] Add PyObject_CallOneArg()

Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +14374 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14558 ___ Python tracker ___

[issue37483] Add PyObject_CallOneArg()

New submission from Jeroen Demeyer : As discussed in https://mail.python.org/archives/list/capi-...@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