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.

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.

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.

OK, I closed this without applying the change. It means one extra special case in PEP 580, but it's not a big deal.