[Python-Dev] Re: [Python-checkins] python/dist/src/Include co mpile.h,2.38,2.39 parsetok.h,2.19,2.20 pyerrors.h,2.63,2.64 pythonrun.h,2 .55,2.56 symtable.h,2.10,2.11

[M.-A. Lemburg]

Mark Hammond wrote:
> [Martin]
> 
>>>OTOH, there are more places left that should accept const strings, but
>>>don't, and I was certainly not out to fix them all. Instead, doing it
>>>on user request only seems right to me. In the long run, we get happy
>>>users because of such changes, which should be weighed against the few
>>>unhappy developers that now have to silence compiler warnings :-)
> 
> [MAL]
> 
>>I would accept that point if you could demonstrate a single
>>case where the const nature of the filename actually does any
>>good for the *user*.
> 
> Well, it depends how you define "user".  When working on win32all, I am a
> developer.  However, when knocking up a simple little extension for Python
> for some silly reason, I feel more like a user.

It is definitely useful for the developer and that's what
I wanted to hint at: the user doesn't notice any change by
introducing "const".

> I'm with Martin on this on; these strings should be const.  It has bitten me
> *lots* of times.  Sometimes as I am implementing someone elses API, am
> passed a "const char *", but can't simply pass it to Python API functions
> that clearly treat the string as const.  Similarly, I tend to personally use
> const for my own APIs where possible, so often I do this just to find my
> const-ness getting in the way.
> 
> I haven't been very vocal about it as I see both side of the const
> argument - but personally lean towards the "const is good" camp.

I'm all for using "const" in new APIs too (I've added it to most
Unicode APIs for that reason), what worries me is that existing APIs
get converted.

>>BTW, how can I silence warnings when writing C code that's
>>supposed to compiler with Python 2.1 and 2.3 ? (passing const char *
>>to a char * API doesn't work for obvious reasons)
> 
> This won't be a problem - continue to personally ignore the "const"
> qualifier.  Then you are passing non-const strings to both the non-const 2.2
> and the const 2.3.
 >
> It is only a problem if you want to take advantage of const - and if you
> object in principle, you probably won't <wink>.  For the rest of us we just
> gotta make the same decision we do these days about Python 1.5 etc - and
> that probably means generally ignoring it for a few years too.

Will do.

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
_______________________________________________________________________
eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,...
Python Consulting:                               http://www.egenix.com/
Python Software:                    http://www.egenix.com/files/python/