[ python-Bugs-1228053 ] usage of type "char*" instead of "const char*"

SourceForge.net noreply at sourceforge.net
Thu Jun 30 23:54:57 CEST 2005


Bugs item #1228053, was opened at 2005-06-27 02:54
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1228053&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.4
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Mattias Ekholm (ekholm)
Assigned to: Nobody/Anonymous (nobody)
Summary: usage of type "char*" instead of "const char*"

Initial Comment:

I suspect that this is problem is not only related
"char*", but to 
most types used in the Python C API. For "char*" is
quite hard
to sircumvent.

Is there any plan to use const for all function parameters 
when the function is not altering its arguments?

regards
Mattias


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2005-06-30 17:54

Message:
Logged In: YES 
user_id=31435

Actually, a crusade wouldn't be welcome.  We have lots of 
experience with crusades, and it's invariably the case that 
when someone checks in a large number of "mindless" 
changes, they introduce subtle bugs.  That's why developers 
are encouraged to make changes like this incrementally, 
when they happen to be working on a specific area 
_anyway_, so that they're wide awake and _thinking_ about 
that area.

Instead, how about naming the top 3 Python C API functions 
that actually get in your way?  Nobody will object to changing 
the signatures of a few functions someone has said are giving 
them actual real-life problems; the chance of screwing up a 
small task like that is tiny; and you'd get _some_ benefit 
soon.  That's better than never getting any <wink>.

----------------------------------------------------------------------

Comment By: Mattias Ekholm (ekholm)
Date: 2005-06-30 16:24

Message:
Logged In: YES 
user_id=889890


I'll try to find self-confidence enough to go on a crusade
myself :-)

But, as a simple user of python libraries. I'm reluctant to
start changing
the code here-and-there.

----------------------------------------------------------------------

Comment By: Mattias Ekholm (ekholm)
Date: 2005-06-30 16:00

Message:
Logged In: YES 
user_id=889890


this is *not* a coding style question and not related to C++, 
in C string constans may reside in read only memory. 

...and it's a nuisance that the python library code is uses
const 
for char* where appropritate. 

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-06-30 15:49

Message:
Logged In: YES 
user_id=31435

It's a valid question, but no, there's no plan to go on a Const 
Crusade.  Developers sometimes add const where it gets in 
the way, if they happen to working in that area anyway.  For 
example, that's how PyDict_GetItemString() grew its const 
char* key argument.  OTOH, PyMapping_GetItemString() 
does not have a const char* key argument, presumably 
because few people use it, and nobody uses it who cared 
enough yet to change it.

As a practical matter, you'd have better luck submitting a 
patch adding const where it's actually gotten in your way 
than hoping someone else will devote the rest of their life to 
slamming in const everywhere it could possibly go.

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-06-30 15:01

Message:
Logged In: YES 
user_id=593130

Coding style questions should be directed to comp.lang.python 
or the corresponding mail list.
In any case, Python is written in C89, not C++

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1228053&group_id=5470


More information about the Python-bugs-list mailing list