[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

Mark Hammond mhammond@skippinet.com.au
Thu, 12 Dec 2002 09:59:07 +1100


[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.

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.

> 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.

Mark.