Many functions use char* where const char* should be used. I've changed this in a few function prototypes which I use while embedding python due to numerous warnings about deprecated casting from string constants to char*.

I was about to submit the very same patch :-)
I missed PyErr_NewException, but you missed the PyMapping_* methods ;)
Please look into this matter. GCC 4.2 has arrived and it has a new
warning. The code:
char* kwlist[] = { "target", "encoding", NULL };
now gives a warning like:
"warning: deprecated conversion from string constant to ‘char*’"
at least when compiling in C++ mode...
This means that people have to declare it as "const char* kwlist", which
will then trigger another warning when calling
PyArg_ParseTupleAndKeywords with such a variable, because the prototype is:
PyAPI_FUNC(int) PyArg_ParseTupleAndKeywords(PyObject *, PyObject *,
const char *, char **,
...);
The "char **" should be "const char **". ext-, any chance you could fix
that too?

There was once a rather long discussion about "const" in
PyArg_ParseTupleAndKeywords:
http://mail.python.org/pipermail/python-dev/2006-February/060689.html
If you don't read it to the end, here is the conclusion:
"""
It sounds like the right answer for Python is to change the signature
of PyArg_ParseTupleAndKeywords() back. We'll fix it when C fixes its
const rules <wink>.
"""
"const char*" was accepted without opposition, though.

Douglas Greiman submitted many similar changes with his issue2135 patch.
His patch also amends documentation, which is missing here.
I am adding dgreiman to the nosy list here to avoid duplication of
effort.
I am -0 on the idea.

For external APIs visible to user code, this can cause some compatibility problems and users may need to at the very least re-compile this code. So -1 here.
For new external APIs, having const wherever appropriate should be considered on a case by case basis.
For internal code this is a good idea, but I wouldn't go mass-slashing all the code base now replacing char* by const char*. Presenting some examples where this makes sense in particular would be interesting though. +0

> For external APIs visible to user code, this can cause some
> compatibility problems and users may need to at the very least
> re-compile this code.
Can you explain exactly which compatibility problems this would cause?
Actually, the point is precisely to make life easier for third-party code, since "const char *" is more accepting than "char *".

The patch is outdated. Some function prototypes were changed in issue9369, some were changed before.
Here is a new patch. It adds const qualifier to following public functions:
PyObject_DelAttrString, PyObject_HasAttrString, PyObject_GetAttrString, PyObject_SetAttrString, PyObject_DelItemString, PyMapping_DelItemString, PyMapping_HasKeyString, PyMapping_GetItemString, PyMapping_SetItemString, PyFile_FromFd, PyImport_ExecCodeModule, PyImport_ExecCodeModuleEx, PyImport_ExecCodeModuleWithPathnames, PyImport_ImportFrozenModule, PyLong_FromString, PyOS_strtoul, PyOS_strtol, PyOS_Readline, PyMarshal_ReadObjectFromString, PyParser_ParseFile, PyParser_ParseFileFlags, PyParser_ParseFileFlagsEx, PyTokenizer_FromFile. It also changes prototypes of some internal functions and structures and fixes documentation for PyDict_DelItemString. Some of functions already were documented with const qualifier.