RE: [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
From: M.-A. Lemburg [mailto:mal@lemburg.com]
I remember Tim opposing such changes (and Greg Stein insisting on them ;-). AFAIK, this breaks third party code since some compilers simply reject casting char* to const char*.
I must admit I caused this recent constifying mess ... someone complained on python-list and I told him to submit a bug report (in the hope that it would get rejected because I knew the problems it would cause). I submit myself for a spanking. Tim Delaney
"Delaney, Timothy" <tdelaney@avaya.com> writes:
I must admit I caused this recent constifying mess ... someone complained on python-list and I told him to submit a bug report (in the hope that it would get rejected because I knew the problems it would cause).
I (obviously) did not feel that the request was misguided. The second on (on RunString) was probably more effort that it will ever do good, but I am convinced that the change is conceptually right, i.e. the strings used as file names and scripts really should be const, as people will pass string literals. 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 :-) Regards, Martin
Martin v. Löwis wrote:
"Delaney, Timothy" <tdelaney@avaya.com> writes:
I must admit I caused this recent constifying mess ... someone complained on python-list and I told him to submit a bug report (in the hope that it would get rejected because I knew the problems it would cause).
I (obviously) did not feel that the request was misguided. The second on (on RunString) was probably more effort that it will ever do good, but I am convinced that the change is conceptually right, i.e. the strings used as file names and scripts really should be const, as people will pass string literals.
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 :-)
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*. 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) -- 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/
"M.-A. Lemburg" <mal@lemburg.com> writes:
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*.
See the original bug report. It avoids having to write const_casts.
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)
Can you explain where such silencing would be necessary, for the specific patch in question? It is not, because non of the variables that got const now are ever passed to 2.1 API: they are all internal to the core. Regards, Martin
Martin v. Löwis wrote:
"M.-A. Lemburg" <mal@lemburg.com> writes:
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*.
See the original bug report. It avoids having to write const_casts.
Great and now those who want to avoid warnings have to patch their old code :-(
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)
Can you explain where such silencing would be necessary, for the specific patch in question? It is not, because non of the variables that got const now are ever passed to 2.1 API: they are all internal to the core.
They are ? The pythonrun.h changes were public in 2.1 as well and they include some of the more common APIs like the PyRun_*() APIs. -- 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/
Great and now those who want to avoid warnings have to patch their old code :-(
Why is that? Nobody has to change anything.
Can you explain where such silencing would be necessary, for the specific patch in question? It is not, because non of the variables that got const now are ever passed to 2.1 API: they are all internal to the core.
They are ? The pythonrun.h changes were public in 2.1 as well and they include some of the more common APIs like the PyRun_*() APIs.
Right. But those changes will no author of extension modules force to change anything. The PyRun_ functions now expect const char*. Existing code will pass char*. No problem, this is well-formed C. In addition, people who want to pass const char* can now do so without using a cast, which they previously couldn't. The only necessary subsequential change is *inside* the PyRun_ functions, where the types of local variables had to be changed, and the types of PyParse_ functions, etc. Developers of the Python core have to keep this in mind when changing the Python core. Nobody else has to change anything. Regards, Martin
[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.
[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.
Folks: I'm just reposting the latest contribution to this thread in an attempt to stop the messages from appearing as attachments. Don't know whether it will work, or why it was happening in the first place ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming http://pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com -----------------------------------------------------------------------
Folks: I'm just reposting the latest contribution to this thread in an attempt to stop the messages from appearing as attachments. Don't know whether it will work,
Sounds as likely to work as gutting a cat and offering the entrails to Barry.
or why it was happening in the first place
It wasn't -- I expect you're the only one who saw attachments. My Outlook 2000 gets into that state sometimes, and is then cured by closing it, using Task Manager to make sure it's gone, and then opening it again.
"TP" == Tim Peters <tim.one@comcast.net> writes:
>> Folks: I'm just reposting the latest contribution to this >> thread in an attempt to stop the messages from appearing as >> attachments. Don't know whether it will work, TP> Sounds as likely to work as gutting a cat and offering the TP> entrails to Barry. I'm much more into fried snakes in my computer's guts: http://www.uq.edu.au/education/extra/all.html -Barry
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/
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 see that my terminology was confusing: user: software author who uses the Python header files. developer: software author who writes them. Strictly speaking, computer users never "use" Python: they always use some Python application. So the Python "users" are always software authors. Of those, only the authors who write C extensions will notice a change. Sorry for the confusion.
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.
No need to worry. Nothing can break because of that. Regards, Martin
participants (8)
-
barry＠python.org -
Delaney, Timothy -
M.-A. Lemburg -
Mark Hammond -
Martin v. Löwis -
martin＠v.loewis.de
-
Steve Holden -
Tim Peters