I'm embedding Python in a C++ application and found myself casting const char* to char* quite often when using functions like PySys_SetObject and PySys_GetObject.

I attached a patch replacing the char* arguments of the above mentioned functions, PySys_GetFile and PySys_AddWarnOption with const char*.

The patch no longer applies to trunk, but that would be trivial to fix.

Changes like these have been accepted with little resistance in the past 
(see e.g. issue651362), so I don't see why this patch has been pending 
for  so long.  (In general, I am -0 on adding const modifiers because 
they tend to trigger an avalanche of changes, but arguably this is the 
"right thing to do.")   

A few comments:

* Documentation needs to be updated in Doc/c-api/sys.rst. 

* Any reason why PySys_SetPath(char *) is left out?

* Same for PySys_SetArgv(int, char **)

* Similar changes are proposed in issue1772673.  Maybe these two issues 
can be dealt with together.

At least a response, finally. 

> * Any reason why PySys_SetPath(char *) is left out?

I guess it I just missed it.
 
> * Same for PySys_SetArgv(int, char **)

That one is non-trivial and requires some rewriting of PySys_SetArgv.
And I didn't have the time to look into it any further.

I attached an updated patch.

The new patch looks fine to me.   It applies and compiles without
warnings and the changes are now reflected in the docs.  I guess
someone would need to write a NEWS entry because it is a public API
change, but otherwise I would say it should be applied.

"[U]nless 'C' has adopted overloading while I wasn't looking ...  it's
hard to imagine what kind of problems you could introduce in `C' code
by changing char* to char const* that wouldn't be caught at
compile-time." (Dave Abrahams in C++-sig)

http://mail.python.org/pipermail/cplusplus-sig/2005-December/009562.html

On Thu, Nov 13, 2008 at 2:24 PM, Sebastian Ramacher
<report@bugs.python.org> wrote:
..
>> * Same for PySys_SetArgv(int, char **)
>
> That one is non-trivial and requires some rewriting of PySys_SetArgv.
> And I didn't have the time to look into it any further.
>
I agree and I only tossed this one in to check if you are aware of the
char ** issues.  I believe it was agreed at some point that changing
char ** to const char ** is not a good idea (see revision 42596
reverting such change), but I could not find a clear explanation of
the associated problems.

In any case, +1 from me in favor of applying this patch and I will try
to add Jeremy Hylton to the "nosy" list since he is the developer who
made similar API changes in r41638 .

Sorry, but it's too late to apply the patch. The issues don't count as
"critical" and it changes the API, too. Only critical and important bugs
are solved during the release candidate phase of 3.0. Python 2.6 is
already out.

I set the target version to 2.7 and 3.1.

While technically this is an API change, in reality it is unlikely to
break anyone's code because you can always pass char * to a function
that expects const char* and the ABI does not change.   (Also I cannot
think why anyone would want to use pointers to the affected functions,
which would be another potential breakage.)

In any case, I am not a big proponent of const correctness, but this
patch was forgotten for 1.5 years and
deferring it to 2.7 and 3.1 is virtually equivalent to closing with "won't fix".

Is it clear that  this patch is not a candidate for minor releases -
2.5.3 or 2.6.1?  As I explained, it is not *really* an API change.  If
it is a backport candidate, I would see benefit in committing it
sooner and blocking in py3k merge until 3.0 is out.

On Thu, Nov 13, 2008 at 4:29 PM, Christian Heimes
<report@bugs.python.org> wrote:
>
> Christian Heimes <lists@cheimes.de> added the comment:
>
> Sorry, but it's too late to apply the patch. The issues don't count as
> "critical" and it changes the API, too. Only critical and important bugs
> are solved during the release candidate phase of 3.0. Python 2.6 is
> already out.
>
> I set the target version to 2.7 and 3.1.
>
> ----------
> stage:  -> patch review
> versions: +Python 2.7, Python 3.1 -Python 2.6
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue1699259>
> _______________________________________
>

Concerning the SetArgv( int, char**), that one will have to be changed
to a SetArgv( int, char const* const*), i.e. applying the const on both
levels. Otherwise, there is no implicit conversion between the two.

The reason is a bit complicated: if the function stored a
pointer-to-const in the array, it would become a pointer-to-nonconst
outside. Only if modification of the array is forbidden, changing the
element type to pointer-to-const is allowed.

Otherwise, I'm +1 on this kind of changes, because it makes immediately
obvious which functions modify a passed buffer and which don't.

See also issue 6952, which seems to be a broader request of the same
nature.  Moving the 3.1 target to 3.2, since 3.1 is out.

Drop 2.7 as that's now gone.  See also #6952.

2.7 is not gone.  It has entered an extended maintenance period.  During this period, 2.7.x releases will incorporate bug fixes but will not get any new features.  This particular issue is arguably a bug.  I think  Christian should make a call on whether this is appropriate for 2.7.

This is quite clearly marked as a feature request and hence is 3.2.  If you wish to change it go ahead, but who's going to do the work?

Any news on that?

On Mon, Oct 18, 2010 at 11:17 AM, Sebastian Ramacher
<report@bugs.python.org> wrote:
..
> Any news on that?

Is this patch still relevant for 3.2?  It looks like const has been
added when char* was changed to wchar_t* in the affected functions.
See r62178.

In fact, it looks like const has been added in py3k as early as r57439.

I am resetting "versions" to 2.7, but I am -0 on backporting.  I am also unselecting "type" because with "feature request" type this should be closed while some may argue that this is a bug.

Since the patches are not applicable to Py 3.x and Py 2.7 is stable I'm closing this bug.