Re: [Python-Dev] NOARGS_NULL

K D schrieb:
I thought it would be nice to have the code marked somehow so that it was obvious what the additional (and obviously unused) parameter was. The two references (NULL and METH_NOARGS) are both in upper-case and as C is a case-sensitive language I think it's probably usual to do case-sensitive greps etc when trying to understand code. Therefore, I thought NOARGS_NULL as a name had enough information in it for someone to "find their way" when looking at the code and wondering what that unused parameter was declared for.
Kev, The style-guide in C is that macro names are spelled in all-caps, so if you see an all-caps identifier, you expect it to be a macro name. Regards, Martin

Martin v. Löwis wrote:
The style-guide in C is that macro names are spelled in all-caps, so if you see an all-caps identifier, you expect it to be a macro name.
Hi Martin. OK, so somewhere we have: /* NOARGS_NULL: A parameter declared in this way is present only because * the function is registered as a METH_NOARGS function. Due to the * way such functions are called [reference], the parameter will always * be NULL (as the name suggests) and should always be ignored. The * reason for this is [reference|"historical"]. */ #define NOARGS_NULL _noargs_null_ ... this is tongue-in-cheek, but I'm only half-joking (perhaps this is an acceptable compromise). My whole reason for naming it that way was to help people who might be grepping through the source to understand what's going on (and the two references/grep strings are in upper-case elsewhere). FWIW, I'm not overly concerned about the spelling - as the SF comment indicated I thought that the all-caps name might be an issue, but really I'd rather you called it "PyObject *_" than not have it in at all because of the amount of work I'd have to do each time there was a new release without it ;) Thanks, Kev.
participants (2)
-
"Martin v. Löwis"
-
K D