[Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification (original) (raw)

Jeremy Hylton jeremy at alum.mit.edu
Tue Feb 14 14:01:10 CET 2006

On 2/14/06, M.-A. Lemburg <mal at egenix.com> wrote:

Martin v. Löwis wrote: > M.-A. Lemburg wrote: >>> It's the consequences: nobody complains about tacking "const" on to a >>> former honest-to-God "char *" argument that was in fact not modified, >>> because that's not only helpful for C++ programmers, it's harmless >>> for all programmers. For example, nobody could sanely object (and >>> nobody did :-)) to adding const to the attribute-name argument in >>> PyObjectSetAttrString(). Sticking to that creates no new problems >>> for anyone, so that's as far as I ever went. >> >> Well, it broke my C extensions... I now have this in my code: >> >> /* The keyword array changed to const char* in Python 2.5 */ >> #if PYVERSIONHEX >= 0x02050000 >> # define PyKEYWORDSSTRINGTYPE const char >> #else >> # define PyKEYWORDSSTRINGTYPE char >> #endif >> ... >> static PyKEYWORDSSTRINGTYPE *kwslist[] = {"yada", NULL}; >> ... > > You did not read Tim's message carefully enough. He wasn't talking > about PyArgParseTupleAndKeywords at all. He only talked about > changing char* arguments to const char*, e.g. in > PyObjectSetAttrString. Did that break your C extensions also?

I did read Tim's post: sorry for phrasing the reply the way I did. I was referring to his statement "nobody complains about tacking "const" on to a former honest-to-God "char *" argument that was in fact not modified". Also: it's not me complaining, it's the compilers !

Tim was talking about adding const to a char* not adding const to a char** (note the two stars). The subsequent discussion has been about the different way those are handled in C and C++ and a general agreement that the "const char**" has been a bother for people.

Jeremy

More information about the Python-Dev mailing list