- Python Home
- About
- News
- Documentation
- Downloads
- Community
- Foundation
- Developer's Guide
- Issue Tracker
- Issues
- Summaries
- User
- Administration
- Help
Issue37499
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2019-07-04 20:29 by p-ganssle, last changed 2022-04-11 14:59 by admin. This issue is now closed.
| Pull Requests | |||
|---|---|---|---|
| URL | Status | Linked | Edit |
| PR 14795 | closed | jdemeyer, 2019-07-16 15:39 | |
| PR 15776 | merged | petr.viktorin, 2019-09-09 13:07 | |
| Messages (5) | |||
|---|---|---|---|
| msg347295 - (view) | Author: Paul Ganssle (p-ganssle) * ![]() |
Date: 2019-07-04 20:29 | |
Currently, `test_pycfunction` picks a few built-in functions with various calling conventions to exercise all the relevant code paths:
for py_name, py_args, c_name, expected_frame_number in (
('gmtime', '', 'time_gmtime', 1), # METH_VARARGS
('len', '[]', 'builtin_len', 2), # METH_O
...
See: https://github.com/python/cpython/blob/2f19e82fbe98ce86bcd98a176328af2808b678e8/Lib/test/test_gdb.py#L851
These calling conventions are not a guaranteed part of the interface, and as such these tests are fragile (as we saw in GH-14311, when converting the time module to use Argument Clinic changed gmtime from METH_VARARGS to METH_FASTCALL). Per Victor's suggestion in GH-14330, I think we should expose a few test functions in the `testcapi` module as exemplars of their respective calling conventions and use those, rather than arbitrary builtins.
|
|||
| msg347314 - (view) | Author: STINNER Victor (vstinner) * ![]() |
Date: 2019-07-05 08:47 | |
> Per Victor's suggestion in GH-14330, I think we should expose a few test functions in the `testcapi` module as exemplars of their respective calling conventions and use those, rather than arbitrary builtins. I suggest to write functions which return their arguments, so we can check that we get what we expect ;-) |
|||
| msg347315 - (view) | Author: STINNER Victor (vstinner) * ![]() |
Date: 2019-07-05 08:52 | |
By the way, PyObject_CallFunction("O") has a surprising behavior: if you pass a tuple, the tuple is unpacked, whereas any other type is passed directly. See bpo-28977.
I would prefer to fix the API since it caused severe bugs in the past, like asyncio generator bug bpo-21209.
But I'm not sure if we can do it without a deprecation period... I'm not sure that we should deprecate anything, since I would expect that PyObject_CallFunction(func, "O", tuple) calls func(tuple) rather than func(*tuple)...
|
|||
| msg351622 - (view) | Author: miss-islington (miss-islington) | Date: 2019-09-10 11:21 | |
New changeset f958377b67c36a98d4df67b94c01eb29e3104f61 by Miss Islington (bot) (Petr Viktorin) in branch 'master': bpo-37499: Test various C calling conventions (GH-15776) https://github.com/python/cpython/commit/f958377b67c36a98d4df67b94c01eb29e3104f61 |
|||
| msg351657 - (view) | Author: Paul Ganssle (p-ganssle) * ![]() |
Date: 2019-09-10 13:36 | |
This is done, thanks Petr and Jeroen! I don't see a need to backport this unless we also want to backport GH-14311 or something else that depends on it. |
|||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022-04-11 14:59:17 | admin | set | github: 81680 |
| 2019-09-10 13:36:38 | p-ganssle | set | status: open -> closed resolution: fixed messages: + msg351657 stage: patch review -> resolved |
| 2019-09-10 11:21:12 | miss-islington | set | nosy:
+ miss-islington messages: + msg351622 |
| 2019-09-09 13:07:29 | petr.viktorin | set | pull_requests: + pull_request15429 |
| 2019-07-16 15:39:23 | jdemeyer | set | keywords:
+ patch stage: needs patch -> patch review pull_requests: + pull_request14589 |
| 2019-07-05 08:52:18 | vstinner | set | messages: + msg347315 |
| 2019-07-05 08:47:49 | vstinner | set | messages: + msg347314 |
| 2019-07-04 20:29:24 | p-ganssle | create | |


