Many Python API functions are causing GCC to rightly complain
that const char * strings are being passed to python functions
that take char * but do not need to modify the args.

g++ reports example.cxx:633: warning: deprecated conversion from string
constant to ‘char*’

The example I encountered today, while testing PyCXX against
G++ 4.2.1 on Mac OS X, was PyObject_CallMethod
but it is not limited to this function.

Would a patch help progress this issue?

A patch would definitely help. Such a patch shouldn't whole-sale replace
char with const char, but selectively only change locations where it is
actually necessary and doesn't hurt.

See also issue #1699259.

I'd guess that this change can first be made against 2.7 and 3.2
so that API's do not change.

Where do I find the source code to generate the patch against
for 2.7 and 3.2?

Take a look at http://www.python.org/dev, specifically the 'How to Get
Started' article (which points you to the developer's FAQ, which
explains how to do an anonymous checkout of the source).

I'm setting the targets to 2.7/3.2 per the discussion in issue #1699259.
 Perhaps the question of whether or not it is "really" an API change
could be revisited, but if so that would probably have to go through
python-dev.

Here is my 1st patch to allow const char * and const Py_UNICODE *
It is agsinst http://svn.python.org/projects/python/trunk.

What I have attempted to do is stop the public API of python needing
char * or Py_UNICODE * where the API clearly does not need to modify
the argument. I have only modified internal API where its necessary
to provide a public const API.

Please give feedback and let me know if you wish me raise anything
with python dev.

I'm happy to produce a 3.2 version of the patch after the 2.7 version
is acceptable.

Barry

Without looking into the details: the places where you cast-away
constness look wrong. Either the parameter shouldn't have been declared
const, or the target of the assignment needs to be converted to const,
too. If the cast is really legitimite, a comment needs to justify it
(but then, I think I would still prefer not to change the parameter to
const).

I was trying to avoid changing the const ness of output parameters.
Given the advice not to go mad on putting const everywhere.

1) I can comment the casts to maintain this goal.
2) Or change the output paramter const ness.

Given your feedback I'm guessing you want me to go further with 
the use of const and do (2).

Barry

> 1) I can comment the casts to maintain this goal.
> 2) Or change the output paramter const ness.
> 
> Given your feedback I'm guessing you want me to go further with 
> the use of const and do (2).

Ah, ok - as I said, I didn't look into detail further. IIUC, changing
output parameters to const could break existing code (right?); this
should be avoided absolutely.

Rather than having the casts, I think I would prefer to take no action
at these places; I recommend to discuss that on python-dev (some may
argue in favor of changing output pointers to const if that is
semantically correct).

Updated patch with comment explaining cast.

Drop 2.7 as it's gone.  See also #1699259.