Re: [Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification
Martin v. Löwis wrote:
M.-A. Lemburg wrote:
It's the consequences: nobody complains about tacking const on to a
former honest-to-God char * argument that was in fact not modified,
because that's not only helpful for C++ programmers, it's _harmless_
for all programmers. For example, nobody could sanely object (and
nobody did :-)) to adding const to the attribute-name argument in
PyObject_SetAttrString(). Sticking to that creates no new problems
for anyone, so that's as far as I ever went.
Well, it broke my C extensions... I now have this in my code:
/* The keyword array changed to const char* in Python 2.5 */
#if PY_VERSION_HEX = 0x0205
# define Py_KEYWORDS_STRING_TYPE const char
#else
# define Py_KEYWORDS_STRING_TYPE char
#endif
...
static Py_KEYWORDS_STRING_TYPE *kwslist[] = {yada, NULL};
...
You did not read Tim's message carefully enough. He wasn't talking
about PyArg_ParseTupleAndKeywords *at all*. He only talked about
changing char* arguments to const char*, e.g. in
PyObject_SetAttrString. Did that break your C extensions also?
I did read Tim's post: sorry for phrasing the reply the way I did.
I was referring to his statement nobody complains about tacking const
on to a former honest-to-God char * argument that was in fact not
modified.
Also: it's not me complaining, it's the compilers !
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Feb 14 2006)
Python/Zope Consulting and Support ...http://www.egenix.com/
mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free !
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification
Thanks to all for a rather insightful discussion, it's always fun to
learn that after 28 years of C programming the language still has
little corners that I know absolutely nothing about:-)
Practically speaking, though, I've adopted MAL's solution for the
time being:
/* The keyword array changed to const char* in Python 2.5 */
#if PY_VERSION_HEX = 0x0205
# define Py_KEYWORDS_STRING_TYPE const char
#else
# define Py_KEYWORDS_STRING_TYPE char
#endif
...
static Py_KEYWORDS_STRING_TYPE *kwslist[] = {yada, NULL};
...
if (!PyArg_ParseTupleAndKeywords(args,kws,format,kwslist,a1))
goto onError;
At least this appears to work...
--
Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma
Goldman
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification
On 2/14/06, M.-A. Lemburg [EMAIL PROTECTED] wrote:
Martin v. Löwis wrote:
M.-A. Lemburg wrote:
It's the consequences: nobody complains about tacking const on to a
former honest-to-God char * argument that was in fact not modified,
because that's not only helpful for C++ programmers, it's _harmless_
for all programmers. For example, nobody could sanely object (and
nobody did :-)) to adding const to the attribute-name argument in
PyObject_SetAttrString(). Sticking to that creates no new problems
for anyone, so that's as far as I ever went.
Well, it broke my C extensions... I now have this in my code:
/* The keyword array changed to const char* in Python 2.5 */
#if PY_VERSION_HEX = 0x0205
# define Py_KEYWORDS_STRING_TYPE const char
#else
# define Py_KEYWORDS_STRING_TYPE char
#endif
...
static Py_KEYWORDS_STRING_TYPE *kwslist[] = {yada, NULL};
...
You did not read Tim's message carefully enough. He wasn't talking
about PyArg_ParseTupleAndKeywords *at all*. He only talked about
changing char* arguments to const char*, e.g. in
PyObject_SetAttrString. Did that break your C extensions also?
I did read Tim's post: sorry for phrasing the reply the way I did.
I was referring to his statement nobody complains about tacking const
on to a former honest-to-God char * argument that was in fact not
modified.
Also: it's not me complaining, it's the compilers !
Tim was talking about adding const to a char* not adding const to a
char** (note the two stars). The subsequent discussion has been about
the different way those are handled in C and C++ and a general
agreement that the const char** has been a bother for people.
Jeremy
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification
On 2/14/06, Martin v. Löwis [EMAIL PROTECTED] wrote: Jeremy Hylton wrote: The compiler in question is gcc and the warning can be turned off with -Wno-write-strings. I think we'd be better off leaving that option on, though. This warning will help me find places where I'm passing a string literal to a function that does not take a const char*. That's valuable, not insensate. Hmm. I'd say this depends on what your reaction to the warning is. If you sprinkle const_casts in the code, nothing is gained. Except for the Python APIs, we would declare the function as taking a const char* if took a const char*. If the function legitimately takes a char*, then you have to change the code to avoid a segfault. Perhaps there is some value in finding functions which ought to expect const char*. For that, occasional checks should be sufficient; I cannot see a point in having code permanently pass with that option. In particular not if you are interfacing with C libraries. I don't understand what you mean: I'm not sure what you mean by occasional checks or permanently pass. The compiler flags are always the same. Jeremy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification
Jeremy Hylton wrote: Perhaps there is some value in finding functions which ought to expect const char*. For that, occasional checks should be sufficient; I cannot see a point in having code permanently pass with that option. In particular not if you are interfacing with C libraries. I don't understand what you mean: I'm not sure what you mean by occasional checks or permanently pass. The compiler flags are always the same. I'm objecting to the this warning should never occur rule. If the warning is turned on in a regular build, then clearly it is desirable to make it go away in all cases, and add work-arounds to make it go away if necessary. This is bad, because it means you add work-arounds to code where really no work-around is necessary (e.g. because it is *known* that some function won't modify the storage behind a char*, even though it doesn't take a const char*). So it is appropriate that the warning generates many false positives. Therefore, it should be a manual interaction to turn this warning on, inspect all the messages, and fix those that need correction, then turn the warning off again. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification
On 2/12/06, Greg Ewing [EMAIL PROTECTED] wrote: [A large head-exploding set of rules] Blarg. Const - Just Say No. +1 -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification
It sounds like the right answer for Python is to change the signature of PyArg_ParseTupleAndKeywords() back. We'll fix it when C fixes its const rules wink. Jeremy On 2/13/06, Guido van Rossum [EMAIL PROTECTED] wrote: On 2/12/06, Greg Ewing [EMAIL PROTECTED] wrote: [A large head-exploding set of rules] Blarg. Const - Just Say No. +1 -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/jeremy%40alum.mit.edu ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification
+1 On 2/13/06, Jeremy Hylton [EMAIL PROTECTED] wrote: It sounds like the right answer for Python is to change the signature of PyArg_ParseTupleAndKeywords() back. We'll fix it when C fixes its const rules wink. Jeremy On 2/13/06, Guido van Rossum [EMAIL PROTECTED] wrote: On 2/12/06, Greg Ewing [EMAIL PROTECTED] wrote: [A large head-exploding set of rules] Blarg. Const - Just Say No. +1 -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/jeremy%40alum.mit.edu -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification
On 2/10/06, Martin v. Löwis [EMAIL PROTECTED] wrote: Jeremy Hylton wrote: Ok. I reviewed the original problem and you're right, the problem was not that it failed outright but that it produced a warning about the deprecated conversion: warning: deprecated conversion from string constant to 'char*'' I work at a place that takes the same attitude as python-dev about warnings: They're treated as errors and you can't check in code that the compiler generates warnings for. In that specific case, I think the compiler's warning should be turned off; it is a bug in the compiler if that specific warning cannot be turned off separately. The compiler in question is gcc and the warning can be turned off with -Wno-write-strings. I think we'd be better off leaving that option on, though. This warning will help me find places where I'm passing a string literal to a function that does not take a const char*. That's valuable, not insensate. Jeremy While it is true that the conversion is deprecated, the C++ standard defines this as Normative for the current edition of the Standard, but not guaranteed to be part of the Standard in future revisions. The current version is from 1998. I haven't been following closely, but I believe there are no plans to actually remove the feature in the next revision. FWIW, Annex D also defines these features as deprecated: - the use of static for objects in namespace scope (AFAICT including C file-level static variables and functions) - C library headers (i.e. stdio.h) Don't you get a warning when including Python.h, because that include limits.h? Nonetheless, the consensus on the c++ sig and python-dev at the time was to fix Python. If we don't allow warnings in our compilations, we shouldn't require our users at accept warnings in theirs. We don't allow warnings for major compilers. This specific compiler appears flawed (or your configuration of it). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification
Tim Peters wrote:
[Jeremy]
I added some const to several API functions that take char* but
typically called by passing string literals.
[Tim]
If he had _stuck_ to that, we wouldn't be having this discussion :-)
(that is, nobody passes string literals to
PyArg_ParseTupleAndKeywords's kws argument).
[Jeremy]
They are passing arrays of string literals. In my mind, that was a
nearly equivalent use case. I believe the C++ compiler complains
about passing an array of string literals to char**.
It's the consequences: nobody complains about tacking const on to a
former honest-to-God char * argument that was in fact not modified,
because that's not only helpful for C++ programmers, it's _harmless_
for all programmers. For example, nobody could sanely object (and
nobody did :-)) to adding const to the attribute-name argument in
PyObject_SetAttrString(). Sticking to that creates no new problems
for anyone, so that's as far as I ever went.
Well, it broke my C extensions... I now have this in my code:
/* The keyword array changed to const char* in Python 2.5 */
#if PY_VERSION_HEX = 0x0205
# define Py_KEYWORDS_STRING_TYPE const char
#else
# define Py_KEYWORDS_STRING_TYPE char
#endif
...
static Py_KEYWORDS_STRING_TYPE *kwslist[] = {yada, NULL};
...
if (!PyArg_ParseTupleAndKeywords(args,kws,format,kwslist,a1))
goto onError;
The crux is that code which should be portable across Python
versions won't work otherwise: you either get Python 2.5 xor
Python 2.x (for x 5) compatibility.
Not too happy about it, but then compared to the ssize_t
changes and the relative imports PEP, this one is an easy
one to handle.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Feb 13 2006)
Python/Zope Consulting and Support ...http://www.egenix.com/
mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free !
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification
Jeremy Hylton wrote: The compiler in question is gcc and the warning can be turned off with -Wno-write-strings. I think we'd be better off leaving that option on, though. This warning will help me find places where I'm passing a string literal to a function that does not take a const char*. That's valuable, not insensate. Hmm. I'd say this depends on what your reaction to the warning is. If you sprinkle const_casts in the code, nothing is gained. Perhaps there is some value in finding functions which ought to expect const char*. For that, occasional checks should be sufficient; I cannot see a point in having code permanently pass with that option. In particular not if you are interfacing with C libraries. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification
M.-A. Lemburg wrote:
It's the consequences: nobody complains about tacking const on to a
former honest-to-God char * argument that was in fact not modified,
because that's not only helpful for C++ programmers, it's _harmless_
for all programmers. For example, nobody could sanely object (and
nobody did :-)) to adding const to the attribute-name argument in
PyObject_SetAttrString(). Sticking to that creates no new problems
for anyone, so that's as far as I ever went.
Well, it broke my C extensions... I now have this in my code:
/* The keyword array changed to const char* in Python 2.5 */
#if PY_VERSION_HEX = 0x0205
# define Py_KEYWORDS_STRING_TYPE const char
#else
# define Py_KEYWORDS_STRING_TYPE char
#endif
...
static Py_KEYWORDS_STRING_TYPE *kwslist[] = {yada, NULL};
...
You did not read Tim's message carefully enough. He wasn't talking
about PyArg_ParseTupleAndKeywords *at all*. He only talked about
changing char* arguments to const char*, e.g. in
PyObject_SetAttrString. Did that break your C extensions also?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification
Martin v. Löwis wrote: then, in C++, 4.4p4 [conv.qual] has a rather longish formula to decide that the assignment is well-formed. In essence, it goes like this: [A large head-exploding set of rules] Blarg. Const - Just Say No. Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification
Greg Ewing wrote: FWIW, Annex D also defines these features as deprecated: - the use of static for objects in namespace scope (AFAICT including C file-level static variables and functions) - C library headers (i.e. stdio.h) Things like this are really starting to get on my groat. It used to be that C++ was very nearly a superset of C, so it was easy to write code that would compile as either. But C++ seems to be evolving into a different language altogether. Not at all. People appear to completely fail to grasp the notion of deprecated in this context. It just means it may go away in a future version, implying that the rest of it may *not* go away in a future version. That future version might get published in 2270, when everybody has switched to C++, and compatibility with C is no longer required. So the compiler is wrong for warning about it (or the user is wrong for asking to get warned), and you are wrong for getting upset about this. (And an obnoxiously authoritarian one at that. If I want to write some C++ code that uses stdio because I happen to like it better, why the heck shouldn't I be allowed to? It's MY program, not the C++ standards board's!) Again, you are misunderstanding what precisely is deprecated. Sure you can still use stdio, and it is never going away (it isn't deprecated). However, you have to spell the header as #include cstdio and then refer to the functions as std::printf, std::stderr, etc. What is really being deprecated here is the global namespace. That's also the reason to deprecate file-level static: you should use anonymous namespaces instead. (Also, just in case this is misunderstood again: it is *not* that programs cannot put stuff in the global namespace anymore. It's just that the standard library should not put stuff in the global namespace). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification
Bengt Richter wrote: Would it make sense to use a typedef for readability's sake? E.g., typedef const char * p_text_literal; and then use p_text_literal, const p_text_literal * in the signature, for read-only access to the data? (hope I got that right). (also testing whether I have been redirected to /dev/null ;-) Nearly. Please try your proposals out in a sandbox before posting. How does this contribute to solving the PyArg_ParseTupleAndKeywords issue? Readability is not the problem that puzzled Jack. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification
On Fri, 10 Feb 2006 18:02:03 +0100, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=
[EMAIL PROTECTED] wrote:
Jeremy Hylton wrote:
I admit that I'm also puzzled by Jack's specific question. I don't
understand why an array passed to PyArg_ParseTupleAndKeywords() would
need to be declared as const. I observed the problem in my initial
changes but didn't think very hard about the cause of the problem.
Perhaps someone with better C/C++ standards chops can explain.
Please take a look at this code:
void foo(const char** x, const char*s)
{
x[0] = s;
}
void bar()
{
char *kwds[] = {0};
const char *s = Text;
foo(kwds, s);
kwds[0][0] = 't';
}
If it was correct, you would be able to modify the const char
array in the string literal, without any compiler errors. The
assignment
x[0] = s;
is kosher, because you are putting a const char* into a
const char* array, and the assigment
kwds[0][0] = 't';
is ok, because you are modifying a char array. So the place
where it has to fail is the passing of the pointer-pointer.
Will a typedef help?
martin.c ---
#include cstdio
typedef const char *ptext;
void foo(ptext *kw)
{
const char *s = Text;
ptext *p;
for(p=kw;*p;p++){ printf(foo:%s\n, *p);}
kw[0] = s;
for(p=kw;*p;p++){ printf(foo2:%s\n, *p);}
kw[0][0] = 't'; /* comment this out and it compiles and runs */
for(p=kw;*p;p++){ printf(foo3:%s\n, *p);}
}
int main()
{
char *kwds[] = {Foo,Bar,0};
char **p;
for(p=kwds;*p;p++){ printf(%s\n, *p);}
foo(kwds);
for(p=kwds;*p;p++){ printf(%s\n, *p);}
}
---
[12:32] C:\pywk\pydevcl martin.c
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8168 for 80x86
Copyright (C) Microsoft Corp 1984-1998. All rights reserved.
martin.c
martin.c(10) : error C2166: l-value specifies const object
But after commenting out:
[12:32] C:\pywk\pydevcl martin.c
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8168 for 80x86
Copyright (C) Microsoft Corp 1984-1998. All rights reserved.
martin.c
Microsoft (R) Incremental Linker Version 6.00.8168
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
/out:martin.exe
martin.obj
[12:34] C:\pywk\pydevmartin
Foo
Bar
foo:Foo
foo:Bar
foo2:Text
foo2:Bar
foo3:Text
foo3:Bar
Text
Bar
Regards,
Bengt Richter
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification
Bengt Richter wrote: Will a typedef help? A typedef can never help. It is always possible to reformulate a program using typedefs to one that doesn't use typedefs. Compiling your program with the const modification line removed gives martin.c: In function 'int main()': martin.c:18: error: invalid conversion from 'char**' to 'const char**' martin.c:18: error: initializing argument 1 of 'void foo(const char**)' Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification
On Sat, Feb 11, 2006, Martin v. L?wis wrote: Not at all. People appear to completely fail to grasp the notion of deprecated in this context. It just means it may go away in a future version, implying that the rest of it may *not* go away in a future version. That future version might get published in 2270, when everybody has switched to C++, and compatibility with C is no longer required. Just for the clarification of those of us who are not C/C++ programmers, are you saying that this is different from the meaning in Python, where deprecated means that something *IS* going away? -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ 19. A language that doesn't affect the way you think about programming, is not worth knowing. --Alan Perlis ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification
On Sat, 11 Feb 2006 14:14:00 +0100, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= [EMAIL PROTECTED] wrote: Bengt Richter wrote: Will a typedef help? A typedef can never help. It is always possible to reformulate a program using typedefs to one that doesn't use typedefs. I realize that's true for a correct compiler, and should have reflected that you aren't just trying to appease a particular possibly quirky one. Compiling your program with the const modification line removed gives martin.c: In function 'int main()': martin.c:18: error: invalid conversion from 'char**' to 'const char**' martin.c:18: error: initializing argument 1 of 'void foo(const char**)' Sorry, I should have tried it with gcc, which does complain: [07:16] /c/pywk/pydevgcc martin.c martin.c: In function `main': martin.c:19: warning: passing arg 1 of `foo' from incompatible pointer type also g++, but not just warning (no a.exe generated) [07:16] /c/pywk/pydevg++ martin.c martin.c: In function `int main()': martin.c:19: invalid conversion from `char**' to `const char**' [07:17] /c/pywk/pydevgcc -v snip full specs gcc version 3.2.3 (mingw special 20030504-1) But Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8168 for 80x86 didn't complain. But then it doesn't complain about const char** x either. I wonder if I have complaints accidentally turned off someplace ;-/ Sorry. Regards, Bengt Richter ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification
Hi Tim, On Fri, Feb 10, 2006 at 12:19:01PM -0500, Tim Peters wrote: Oh, who cares? I predict Jack's problem would go away if we changed the declaration of PyArg_ParseTupleAndKeywords to what you intended wink to begin with: PyAPI_FUNC(int) PyArg_ParseTupleAndKeywords(PyObject *, PyObject *, const char *, const char * const *, ...); Alas, this doesn't make gcc happy either. (I'm trying gcc 3.4.4.) In theory, it prevents the const-bypassing trick showed by Martin, but apparently the C standard (or gcc) is not smart enough to realize that. I don't see a way to spell it in C so that the same extension module compiles with 2.4 and 2.5 without a warning, short of icky macros. A bientot, Armin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification
Martin v. Löwis wrote: That future version might get published in 2270, There are *already* differences which make C and C++ annoyingly incompatible. One is the const char * const * issue that appeared here. Another is that it no longer seems to be permissible to forward-declare static things, which has caused me trouble with Pyrex. That's not just a deprecation -- some compilers refuse to compile it at all. Personally I wouldn't mind about these things, as I currently don't care if I never write another line of C++ in my life. But if e.g. Pyrex-generated code is to interoperate with other people's C++ code, I need to worry about these issues. when everybody has switched to C++, and compatibility with C is no longer required. Yeeks, I hope not! The world needs *less* C++, not more... Sure you can still use stdio, and it is never going away (it isn't deprecated). However, you have to spell the header as #include cstdio and then refer to the functions as std::printf, std::stderr, etc. Which makes it a very different language from C in this area. That's my point. Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification
Aahz wrote: That future version might get published in 2270, when everybody has switched to C++, and compatibility with C is no longer required. Just for the clarification of those of us who are not C/C++ programmers, are you saying that this is different from the meaning in Python, where deprecated means that something *IS* going away? To repeat the literal words from the standard: Annex D [depr]: 1 This clause describes features of the C++ Standard that are specified for compatibility with existing implementations. 2 These are deprecated features, where deprecated is defined as: Normative for the current edition of the Standard, but not guaranteed to be part of the Standard in future revisions. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification
Greg Ewing wrote: There are *already* differences which make C and C++ annoyingly incompatible. One is the const char * const * issue that appeared here. Of course there are differences. C++ has classes, C doesn't. C++ has function overloading, C doesn't. C++ has assignment from char** to const char*const*, C doesn't. Why is it annoying that C++ extends C? Another is that it no longer seems to be permissible to forward-declare static things, Not sure what you are referring to. You can forward-declare static functions in C++ just fine. when everybody has switched to C++, and compatibility with C is no longer required. Yeeks, I hope not! The world needs *less* C++, not more... I'm sure the committee waits until you retire before deciding that compatibility with C is not needed anymore :-) Sure you can still use stdio, and it is never going away (it isn't deprecated). However, you have to spell the header as #include cstdio and then refer to the functions as std::printf, std::stderr, etc. Which makes it a very different language from C in this area. That's my point. That future version of C++ to be published in 2270, yes, it will be different from C, because the last C programmer will have died 20 years ago. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification
OMG. Are we now adding 'const' modifiers to random places? I thought
const propagation hell was a place we were happily avoiding by not
falling for that meme. What changed?
--Guido
On 2/10/06, Jack Jansen [EMAIL PROTECTED] wrote:
I keep running into problems with the const modifications to
PyArg_ParseTupleAndKeywords() (rev. 41638 by Jeremy).
I have lots of code of the form
char *kw[] = {itself, 0};
if (PyArg_ParseTupleAndKeywords(_args, _kwds, O, kw,
CFTypeRefObj_Convert, itself)) ...
which now no longer compiles, neither with C nor with C++ (gcc4, both
MacOSX and Linux). Changing the kw declaration to const char *kw[]
makes it compile again.
I don't understand why it doesn't compile: even though the
PyArg_ParseTupleAndKeywords signature promises that it won't change
the kw argument I see no reason why I shouldn't be able to pass a
non-const argument.
And to make matters worse adding the const of course makes the code
non-portable to previous versions of Python (where the C compiler
rightly complains that I'm passing a const object through a non-const
parameter).
Can anyone enlighten me?
--
Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma
Goldman
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/guido%40python.org
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification
On 2/10/06, Guido van Rossum [EMAIL PROTECTED] wrote:
OMG. Are we now adding 'const' modifiers to random places? I thought
const propagation hell was a place we were happily avoiding by not
falling for that meme. What changed?
I added some const to several API functions that take char* but
typically called by passing string literals. In C++, a string literal
is a const char* so you need to add a const_cast to every call site,
which is incredibly cumbersome. After some discussion on python-dev,
I made changes to a small set of API functions and chased the
const-ness the rest of the way, as you would expect. There was
nothing random about the places const was added.
I admit that I'm also puzzled by Jack's specific question. I don't
understand why an array passed to PyArg_ParseTupleAndKeywords() would
need to be declared as const. I observed the problem in my initial
changes but didn't think very hard about the cause of the problem.
Perhaps someone with better C/C++ standards chops can explain.
Jeremy
--Guido
On 2/10/06, Jack Jansen [EMAIL PROTECTED] wrote:
I keep running into problems with the const modifications to
PyArg_ParseTupleAndKeywords() (rev. 41638 by Jeremy).
I have lots of code of the form
char *kw[] = {itself, 0};
if (PyArg_ParseTupleAndKeywords(_args, _kwds, O, kw,
CFTypeRefObj_Convert, itself)) ...
which now no longer compiles, neither with C nor with C++ (gcc4, both
MacOSX and Linux). Changing the kw declaration to const char *kw[]
makes it compile again.
I don't understand why it doesn't compile: even though the
PyArg_ParseTupleAndKeywords signature promises that it won't change
the kw argument I see no reason why I shouldn't be able to pass a
non-const argument.
And to make matters worse adding the const of course makes the code
non-portable to previous versions of Python (where the C compiler
rightly complains that I'm passing a const object through a non-const
parameter).
Can anyone enlighten me?
--
Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma
Goldman
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/guido%40python.org
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/jeremy%40alum.mit.edu
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification
On Fri, Feb 10, 2006 at 11:30:30AM -0500, Jeremy Hylton wrote: On 2/10/06, Guido van Rossum [EMAIL PROTECTED] wrote: OMG. Are we now adding 'const' modifiers to random places? I thought const propagation hell was a place we were happily avoiding by not falling for that meme. What changed? I added some const to several API functions that take char* but typically called by passing string literals. In C++, a string literal is a const char* so you need to add a const_cast to every call site, which is incredibly cumbersome. After some discussion on python-dev, I made changes to a small set of API functions and chased the const-ness the rest of the way, as you would expect. There was nothing random about the places const was added. I admit that I'm also puzzled by Jack's specific question. I don't understand why an array passed to PyArg_ParseTupleAndKeywords() would need to be declared as const. I observed the problem in my initial changes but didn't think very hard about the cause of the problem. Perhaps someone with better C/C++ standards chops can explain. Well, it's counter-intuitive, but a direct result of how pointer equivalence is defined in C. I'm rusty in this part, so I will get some terminology wrong, but IIRC, a variable A is of an equivalent type of variable B if they hold the same type of data. So, a 'const char *' is equivalent to a 'char *' because they both hold the memory of a 'char'. But a 'const char**' (or 'const *char[]') is not equivalent to a 'char **' (or 'char *[]') because the first holds the address of a 'const char *', and the second the address of a 'char *'. A 'char * const *' is equivalent to a 'char **' though. As I said, I got some of the terminology wrong, but the end result is exactly that: a 'const char **' is not equivalent to a 'char **', even though a 'const char *' is equivalent to a 'char *'. Equivalence, in this case, means 'can be automatically downcasted'. Peter v/d Linden explains this quite well in Expert C Programming (aka 'Deep C Secrets'), but unfortunately I'm working from home and I left my copy at a coworkers' desk. -- Thomas Wouters [EMAIL PROTECTED] Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification
Jeremy Hylton wrote:
I admit that I'm also puzzled by Jack's specific question. I don't
understand why an array passed to PyArg_ParseTupleAndKeywords() would
need to be declared as const. I observed the problem in my initial
changes but didn't think very hard about the cause of the problem.
Perhaps someone with better C/C++ standards chops can explain.
Please take a look at this code:
void foo(const char** x, const char*s)
{
x[0] = s;
}
void bar()
{
char *kwds[] = {0};
const char *s = Text;
foo(kwds, s);
kwds[0][0] = 't';
}
If it was correct, you would be able to modify the const char
array in the string literal, without any compiler errors. The
assignment
x[0] = s;
is kosher, because you are putting a const char* into a
const char* array, and the assigment
kwds[0][0] = 't';
is ok, because you are modifying a char array. So the place
where it has to fail is the passing of the pointer-pointer.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification
It looks like a solution may be to define it as const char * const *
rather than const char **. I'll see if that works.
Jeremy
On 2/10/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
Jeremy Hylton wrote:
I admit that I'm also puzzled by Jack's specific question. I don't
understand why an array passed to PyArg_ParseTupleAndKeywords() would
need to be declared as const. I observed the problem in my initial
changes but didn't think very hard about the cause of the problem.
Perhaps someone with better C/C++ standards chops can explain.
Please take a look at this code:
void foo(const char** x, const char*s)
{
x[0] = s;
}
void bar()
{
char *kwds[] = {0};
const char *s = Text;
foo(kwds, s);
kwds[0][0] = 't';
}
If it was correct, you would be able to modify the const char
array in the string literal, without any compiler errors. The
assignment
x[0] = s;
is kosher, because you are putting a const char* into a
const char* array, and the assigment
kwds[0][0] = 't';
is ok, because you are modifying a char array. So the place
where it has to fail is the passing of the pointer-pointer.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification
Jeremy Hylton wrote: I added some const to several API functions that take char* but typically called by passing string literals. In C++, a string literal is a const char* so you need to add a const_cast to every call site, That's not true. A string literal of length N is of type const char[N+1]. However, a (deprecated) conversion of string literals to char* is provided in the language. So assigning a string literal to char* or passing it in a char* parameter is compliant with standard C++, no const_cast is required. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification
On 2/10/06, Martin v. Löwis [EMAIL PROTECTED] wrote: Jeremy Hylton wrote: I added some const to several API functions that take char* but typically called by passing string literals. In C++, a string literal is a const char* so you need to add a const_cast to every call site, That's not true. A string literal of length N is of type const char[N+1]. However, a (deprecated) conversion of string literals to char* is provided in the language. So assigning a string literal to char* or passing it in a char* parameter is compliant with standard C++, no const_cast is required. Ok. I reviewed the original problem and you're right, the problem was not that it failed outright but that it produced a warning about the deprecated conversion: warning: deprecated conversion from string constant to 'char*'' I work at a place that takes the same attitude as python-dev about warnings: They're treated as errors and you can't check in code that the compiler generates warnings for. Nonetheless, the consensus on the c++ sig and python-dev at the time was to fix Python. If we don't allow warnings in our compilations, we shouldn't require our users at accept warnings in theirs. Jeremy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification
[Jeremy Hylton] ... I admit that I'm also puzzled by Jack's specific question. I don't understand why an array passed to PyArg_ParseTupleAndKeywords() would need to be declared as const. I observed the problem in my initial changes but didn't think very hard about the cause of the problem. Perhaps someone with better C/C++ standards chops can explain. Oh, who cares? I predict Jack's problem would go away if we changed the declaration of PyArg_ParseTupleAndKeywords to what you intended wink to begin with: PyAPI_FUNC(int) PyArg_ParseTupleAndKeywords(PyObject *, PyObject *, const char *, const char * const *, ...); That is, declare the keywords argument as a pointer to const pointer to const char, rather than the current pointer to pointer to const char. How about someone on a Linux box try that with gcc, and check it in if it solves Jack's problem (meaning that gcc stops whining about the original spelling of his original example). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification
On 2/10/06, Jeremy Hylton [EMAIL PROTECTED] wrote:
It looks like a solution may be to define it as const char * const *
rather than const char **. I'll see if that works.
No. It doesn't work. I'm not sure about this one either, but some
searching suggests that you can pass a char** to a function taking
const char* const* in C++ but not in C. Sigh. I don't see any way to
avoid a warning in Jack's case.
Jeremy
Jeremy
On 2/10/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
Jeremy Hylton wrote:
I admit that I'm also puzzled by Jack's specific question. I don't
understand why an array passed to PyArg_ParseTupleAndKeywords() would
need to be declared as const. I observed the problem in my initial
changes but didn't think very hard about the cause of the problem.
Perhaps someone with better C/C++ standards chops can explain.
Please take a look at this code:
void foo(const char** x, const char*s)
{
x[0] = s;
}
void bar()
{
char *kwds[] = {0};
const char *s = Text;
foo(kwds, s);
kwds[0][0] = 't';
}
If it was correct, you would be able to modify the const char
array in the string literal, without any compiler errors. The
assignment
x[0] = s;
is kosher, because you are putting a const char* into a
const char* array, and the assigment
kwds[0][0] = 't';
is ok, because you are modifying a char array. So the place
where it has to fail is the passing of the pointer-pointer.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification
[Jeremy] It looks like a solution may be to define it as const char * const * rather than const char **. I'll see if that works. [Jeremy] No. It doesn't work. I'm not sure about this one either, but some searching suggests that you can pass a char** to a function taking const char* const* in C++ but not in C. Oops! I think that's right. Sigh. I don't see any way to avoid a warning in Jack's case. Martin's turn ;-) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification
On 2/10/06, Jeremy Hylton [EMAIL PROTECTED] wrote: I added some const to several API functions that take char* but typically called by passing string literals. In C++, a string literal is a const char* so you need to add a const_cast to every call site, which is incredibly cumbersome. After some discussion on python-dev, I made changes to a small set of API functions and chased the const-ness the rest of the way, as you would expect. There was nothing random about the places const was added. I still don't understand *why* this was done, nor how the set of functions was chosen if not randomly. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification
[Jeremy] I added some const to several API functions that take char* but typically called by passing string literals. In C++, a string literal is a const char* so you need to add a const_cast to every call site, which is incredibly cumbersome. After some discussion on python-dev, I made changes to a small set of API functions and chased the const-ness the rest of the way, as you would expect. There was nothing random about the places const was added. [Guido] I still don't understand *why* this was done, Primarily to make life easier for C++ programmers using Python's C API. But didn't Jeremy just say that? Some people (including me) have been adding const to char* API arguments for years, but in much slower motion, and at least I did it only when someone complained about a specific function. nor how the set of functions was chosen if not randomly. [Jeremy] I added some const to several API functions that take char* but typically called by passing string literals. If he had _stuck_ to that, we wouldn't be having this discussion :-) (that is, nobody passes string literals to PyArg_ParseTupleAndKeywords's kws argument). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification
On 2/10/06, Tim Peters [EMAIL PROTECTED] wrote: [Jeremy] I added some const to several API functions that take char* but typically called by passing string literals. If he had _stuck_ to that, we wouldn't be having this discussion :-) (that is, nobody passes string literals to PyArg_ParseTupleAndKeywords's kws argument). They are passing arrays of string literals. In my mind, that was a nearly equivalent use case. I believe the C++ compiler complains about passing an array of string literals to char**. Jeremy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification
On 2/10/06, Tim Peters [EMAIL PROTECTED] wrote: [Jeremy] I added some const to several API functions that take char* but typically called by passing string literals. In C++, a string literal is a const char* so you need to add a const_cast to every call site, which is incredibly cumbersome. After some discussion on python-dev, I made changes to a small set of API functions and chased the const-ness the rest of the way, as you would expect. There was nothing random about the places const was added. [Guido] I still don't understand *why* this was done, Primarily to make life easier for C++ programmers using Python's C API. But didn't Jeremy just say that? I didn't connect the dots. Some people (including me) have been adding const to char* API arguments for years, but in much slower motion, and at least I did it only when someone complained about a specific function. nor how the set of functions was chosen if not randomly. [Jeremy] I added some const to several API functions that take char* but typically called by passing string literals. If he had _stuck_ to that, we wouldn't be having this discussion :-) (that is, nobody passes string literals to PyArg_ParseTupleAndKeywords's kws argument). Is it too late to revert this one? Is there another way to make C++ programmers happy (e.g. my having a macro that expands to const when compiled with C++ but vanishes when compiled with C?) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification
[Jeremy] I added some const to several API functions that take char* but typically called by passing string literals. [Tim] If he had _stuck_ to that, we wouldn't be having this discussion :-) (that is, nobody passes string literals to PyArg_ParseTupleAndKeywords's kws argument). [Jeremy] They are passing arrays of string literals. In my mind, that was a nearly equivalent use case. I believe the C++ compiler complains about passing an array of string literals to char**. It's the consequences: nobody complains about tacking const on to a former honest-to-God char * argument that was in fact not modified, because that's not only helpful for C++ programmers, it's _harmless_ for all programmers. For example, nobody could sanely object (and nobody did :-)) to adding const to the attribute-name argument in PyObject_SetAttrString(). Sticking to that creates no new problems for anyone, so that's as far as I ever went. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification
On 2/10/06, Guido van Rossum [EMAIL PROTECTED] wrote: On 2/10/06, Tim Peters [EMAIL PROTECTED] wrote: [Jeremy] I added some const to several API functions that take char* but typically called by passing string literals. If he had _stuck_ to that, we wouldn't be having this discussion :-) (that is, nobody passes string literals to PyArg_ParseTupleAndKeywords's kws argument). Is it too late to revert this one? The change is still beneficial to C++ programmers, so my initial preference is to keep it. There are still some benefits to the other changes, so it's isn't a complete loss if we revert it. Is there another way to make C++ programmers happy (e.g. my having a macro that expands to const when compiled with C++ but vanishes when compiled with C?) Sounds icky. Are we pretty sure there is no way to do the right thing in plain C? That is, declare the argument as taking a set of const strings and still allow non-const strings to be passed without warning. Jeremy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification
Jeremy Hylton wrote: Ok. I reviewed the original problem and you're right, the problem was not that it failed outright but that it produced a warning about the deprecated conversion: warning: deprecated conversion from string constant to 'char*'' I work at a place that takes the same attitude as python-dev about warnings: They're treated as errors and you can't check in code that the compiler generates warnings for. In that specific case, I think the compiler's warning should be turned off; it is a bug in the compiler if that specific warning cannot be turned off separately. While it is true that the conversion is deprecated, the C++ standard defines this as Normative for the current edition of the Standard, but not guaranteed to be part of the Standard in future revisions. The current version is from 1998. I haven't been following closely, but I believe there are no plans to actually remove the feature in the next revision. FWIW, Annex D also defines these features as deprecated: - the use of static for objects in namespace scope (AFAICT including C file-level static variables and functions) - C library headers (i.e. stdio.h) Don't you get a warning when including Python.h, because that include limits.h? Nonetheless, the consensus on the c++ sig and python-dev at the time was to fix Python. If we don't allow warnings in our compilations, we shouldn't require our users at accept warnings in theirs. We don't allow warnings for major compilers. This specific compiler appears flawed (or your configuration of it). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification
Martin v. Löwis wrote: FWIW, Annex D also defines these features as deprecated: - the use of static for objects in namespace scope (AFAICT including C file-level static variables and functions) - C library headers (i.e. stdio.h) Things like this are really starting to get on my groat. It used to be that C++ was very nearly a superset of C, so it was easy to write code that would compile as either. But C++ seems to be evolving into a different language altogether. (And an obnoxiously authoritarian one at that. If I want to write some C++ code that uses stdio because I happen to like it better, why the heck shouldn't I be allowed to? It's MY program, not the C++ standards board's!) Sorry, I just had to say that. Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification
On Fri, 10 Feb 2006 17:53:39 +0100, Thomas Wouters [EMAIL PROTECTED] wrote: On Fri, Feb 10, 2006 at 11:30:30AM -0500, Jeremy Hylton wrote: On 2/10/06, Guido van Rossum [EMAIL PROTECTED] wrote: OMG. Are we now adding 'const' modifiers to random places? I thought const propagation hell was a place we were happily avoiding by not falling for that meme. What changed? I added some const to several API functions that take char* but typically called by passing string literals. In C++, a string literal is a const char* so you need to add a const_cast to every call site, which is incredibly cumbersome. After some discussion on python-dev, I made changes to a small set of API functions and chased the const-ness the rest of the way, as you would expect. There was nothing random about the places const was added. I admit that I'm also puzzled by Jack's specific question. I don't understand why an array passed to PyArg_ParseTupleAndKeywords() would need to be declared as const. I observed the problem in my initial changes but didn't think very hard about the cause of the problem. Perhaps someone with better C/C++ standards chops can explain. Well, it's counter-intuitive, but a direct result of how pointer equivalence is defined in C. I'm rusty in this part, so I will get some terminology wrong, but IIRC, a variable A is of an equivalent type of variable B if they hold the same type of data. So, a 'const char *' is equivalent to a 'char *' because they both hold the memory of a 'char'. But a 'const char**' (or 'const *char[]') is not equivalent to a 'char **' (or 'char *[]') because the first holds the address of a 'const char *', and the second the address of a 'char *'. A 'char * const *' is equivalent to a 'char **' though. As I said, I got some of the terminology wrong, but the end result is exactly that: a 'const char **' is not equivalent to a 'char **', even though a 'const char *' is equivalent to a 'char *'. Equivalence, in this case, means 'can be automatically downcasted'. Peter v/d Linden explains this quite well in Expert C Programming (aka 'Deep C Secrets'), but unfortunately I'm working from home and I left my copy at a coworkers' desk. Would it make sense to use a typedef for readability's sake? E.g., typedef const char * p_text_literal; and then use p_text_literal, const p_text_literal * in the signature, for read-only access to the data? (hope I got that right). (also testing whether I have been redirected to /dev/null ;-) Regards, Bengt Richter ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
