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.

Title: METH_NOARGS: no longer require that second arg is NULL
Type: enhancement Stage: resolved
Components: Interpreter Core Versions: Python 3.8
Status: closed Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: jdemeyer, rhettinger, scoder
Priority: normal Keywords: patch

Created on 2018-07-30 11:56 by jdemeyer, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 8563 closed jdemeyer, 2018-07-30 11:59
Messages (4)
msg322670 - (view) Author: Jeroen Demeyer (jdemeyer) * (Python triager) Date: 2018-07-30 11:56
A C function with signature METH_NOARGS takes two arguments where the first is "self" and the second is guaranteed to be NULL. Given that this second argument really should never be used, I would like to drop the guarantee that the argument is NULL.

Concretely, I propose to change:

1. the documentation for METH_NOARGS

2. some functions in Modules/_io/bufferedio.c which actually do use the second argument of a METH_NOARGS function.

For the moment, the second argument is still NULL, but one is not supposed to rely on that.

The reason for this patch is that this second argument can be re-purposed in PEP 580 (and possibly PEP 573) to pass the function object.
msg322706 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2018-07-31 01:02
ISTM it would be better to keep METH_NOARGS as-is and if you need another argument, then use a different calling pattern.  The METH_NOARGS flag is very old and widely adopted -- it is unknowable how changing the assumptions will affect deployed code.  Also, it just feels weird to go down the proposed path -- for clarity, METH_NOARGS should mean "no args" -- any other meaning is certain to create confusion.
msg322720 - (view) Author: Stefan Behnel (scoder) * (Python committer) Date: 2018-07-31 05:29
Agree with Raymond. If the goal is to pass something else, then functions that want to make use of that "something else" have to be modified anyway, in which case also changing the call type wouldn't hurt (assuming the new value still fits into the flag options, but it should).

Only drawback is that adding a new calling convention breaks *calling* code that does not go through the C-API for calling functions, or that otherwise makes direct use of the calling convention flags. But that should be very rare and I think it's acceptable to require such code to be adapted. It would very likely be amongst the beneficiaries of the proposed calling changes anyway.
msg322735 - (view) Author: Jeroen Demeyer (jdemeyer) * (Python triager) Date: 2018-07-31 06:59
OK, I closed this without applying the change. It means one extra special case in PEP 580, but it's not a big deal.
Date User Action Args
2022-04-11 14:59:04adminsetgithub: 78461
2018-07-31 06:59:28jdemeyersetmessages: + msg322735
2018-07-31 06:57:59jdemeyersetstatus: open -> closed
stage: patch review -> resolved
2018-07-31 05:29:54scodersetnosy: + scoder
messages: + msg322720
2018-07-31 01:02:47rhettingersetnosy: + rhettinger
messages: + msg322706
2018-07-30 11:59:29jdemeyersetkeywords: + patch
stage: patch review
pull_requests: + pull_request8077
2018-07-30 11:56:35jdemeyercreate