Re: [Python-Dev] PyRange_New() alternative?
Scott David Daniels wrote: I am not sure about your compiler, but if I remember the standard correctly, the following code shouldn't complain: PyObject_CallFunction((PyObject*) (void *) PyRange_Type, lll, start, start+len*step, step) You remember the standard incorrectly. Python's usage of casts has undefined behaviour, and adding casts only makes the warning go away, but does not make the problem go away. 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] PyRange_New() alternative?
Ralf W. Grosse-Kunstleve wrote: I am not an expert of the C/C++ language details, but the intermediate cast seems to be a great local alternative to the global -fno-strict-aliasing flag. Depends on what you want to achieve. If you just want to make the warning go away, the cast works fine. If you want to avoid bad code being generated, you better use the flag (alternatively, you could fix Python to not rely on undefined behaviour (and no, it's not easy to fix in Python, or else we would have fixed it long 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] PyRange_New() alternative?
--- Martin v. Löwis [EMAIL PROTECTED] wrote: Scott David Daniels wrote: I am not sure about your compiler, but if I remember the standard correctly, the following code shouldn't complain: PyObject_CallFunction((PyObject*) (void *) PyRange_Type, lll, start, start+len*step, step) You remember the standard incorrectly. There are three standards to consider: C89/90, C99, C++97/98. Here you can find the opinion of one of the authors of the C++ standard in this matter: http://mail.python.org/pipermail/c++-sig/2005-December/009869.html __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ 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] PyRange_New() alternative?
Ralf W. Grosse-Kunstleve wrote: You remember the standard incorrectly. There are three standards to consider: C89/90, C99, C++97/98. Here you can find the opinion of one of the authors of the C++ standard in this matter: http://mail.python.org/pipermail/c++-sig/2005-December/009869.html This might be out of context, but Dave Abrahams comment C++ doesn't support the C99 restrict feature. seems irrelevant: C++ certain does not have the restrict keyword, but it has the same aliasing rules as C89 and C99. The specific problem exists in all three languages. 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] PyRange_New() alternative?
Martin v. Löwis wrote: Scott David Daniels wrote: ... if I remember the standard correctly, the following code shouldn't complain: PyObject_CallFunction((PyObject*) (void *) PyRange_Type, lll, start, start+len*step, step) You remember the standard incorrectly. Python's usage of casts has undefined behaviour, and adding casts only makes the warning go away, but does not make the problem go away. ... (PyObject*) PyRange_Type, ... should only work in the presence of subtypes (which C89 and C99 don't define). If there were a way to declare PyTypeObject as a subtype of PyObject then this cast should work. ... (PyObject*) (void *) PyRange_Type, ... Says a pointer to PyRange_Type should have the structure of a pointer PyObject. Since the prelude to PyTypeObject matches that of PyObject, this should be an effective cast. In addition, casting pointers to and from void * should be silent -- _that_ is what I thought I was remembering of the standard. Do not mistake this for advocacy of changing Python's macros; I was telling the OP how he could shut up the complaint he was getting. In C extensions I'd be likely to do the convert through void * trick myself. -- Scott David Daniels [EMAIL PROTECTED] ___ 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] PyRange_New() alternative?
--- Tim Peters [EMAIL PROTECTED] wrote: [Ralf W. Grosse-Kunstleve] Thanks! This does the trick for me: #if PY_VERSION_HEX = 0x0203 PyObject_CallFunction( (PyObject*) PyRange_Type, lll, start, start+len*step, step) Note that this is extremely lax about possible overflow in the arithmetic. For that reason it can't be recommend for general use. #else PyRange_New(start, len, step, 1) #endif I've tested this with Python 2.2.3, 2.3.4, 2.4.3, 2.5b1. Python 2.2.3 (RedHat WS 3) compiles the PyRange_Type call, but there is a runtime error: TypeError: cannot create 'xrange' instances Sorry, I didn't follow that. The only mention of PyRange_Type in the #if'ed code above is in a block that looks like it should be entirely ignored in a 2.2.3 Python (provided you're using the right header files and the C compiler isn't broken). First I tried the PyRange_Type code with Python 2.2.3 and no #ifdef. I resorted to the #ifdef and the old PyRange_New() call only because it didn't work. Compile all of Python that way, and you'll probably see more of those than you can count ;-) Python is normally compiled with, and is _intended_ to be compiled with, -fno-strict-aliasing If you didn't do that, try it. I missed this. Thanks for pointing it out. Since it was never documented to begin with, it was a use at your own risk thing anyway. As you're currently it's only known user throughout all of history :-), if you do all the work of rehabilitating it, I'd be at best a weak -1 anyway: one of the problems with PyRange_New was that its signature was wildly different than the builtin range()'s. That made it a poor API for surprise, surprise! reasons alone. That was a mistake, and I'd rather inconvenience you than pass that mistake on to our precious children ;-) I agree, although I find it hard to believe I am that unique. I'll google for PyRange_New in a couple of years to see how many more people got stranded. :-) Although it will bias the measure of my uniqueness, I still believe you should tell people in the documentation what to do, e.g. PyObject_CallFunction((PyObject*) PyRange_Type, lll, start, stop, step) which avoids showing the sloppy start+len*step hack. BTW: by the time my children pick up programming nobody under 30 will use C Python anymore. ;-) __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ 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] PyRange_New() alternative?
Ralf W. Grosse-Kunstleve wrote: Thanks! This does the trick for me: #if PY_VERSION_HEX = 0x0203 PyObject_CallFunction( (PyObject*) PyRange_Type, lll, start, start+len*step, step) #else PyRange_New(start, len, step, 1) #endif I am compiling the code above with a C++ compiler (in the context of Boost.Python). Newer g++ versions unfortunatly produce a warning if -Wall is specified: warning: dereferencing type-punned pointer will break strict-aliasing rules I am not sure about your compiler, but if I remember the standard correctly, the following code shouldn't complain: PyObject_CallFunction((PyObject*) (void *) PyRange_Type, lll, start, start+len*step, step) -- Scott David Daniels [EMAIL PROTECTED] ___ 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] PyRange_New() alternative?
--- Scott David Daniels [EMAIL PROTECTED] wrote: Ralf W. Grosse-Kunstleve wrote: Thanks! This does the trick for me: #if PY_VERSION_HEX = 0x0203 PyObject_CallFunction( (PyObject*) PyRange_Type, lll, start, start+len*step, step) #else PyRange_New(start, len, step, 1) #endif I am compiling the code above with a C++ compiler (in the context of Boost.Python). Newer g++ versions unfortunatly produce a warning if -Wall is specified: warning: dereferencing type-punned pointer will break strict-aliasing rules I am not sure about your compiler, but if I remember the standard correctly, the following code shouldn't complain: PyObject_CallFunction((PyObject*) (void *) PyRange_Type, lll, start, start+len*step, step) Thanks for the suggestion! I just tried: g++ (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-20) g++ (GCC) 3.4.2 20041017 (Red Hat 3.4.2-6.fc3) g++ (GCC) 4.0.0 20050519 (Red Hat 4.0.0-8) with -Wall -Wno-sign-compare. These compilers don't issue the will break strict-aliasing rules warning with or without the intermediate (void *). However, I also tried: g++ (GCC) 4.1.0 20060304 (Red Hat 4.1.0-3) which issues the warning without the (void *), but not with the (void *). I am not an expert of the C/C++ language details, but the intermediate cast seems to be a great local alternative to the global -fno-strict-aliasing flag. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ 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] PyRange_New() alternative?
Ralf W. Grosse-Kunstleve wrote: http://docs.python.org/dev/whatsnew/ports.html says: The PyRange_New() function was removed. It was never documented, never used in the core code, and had dangerously lax error checking. I use this function (don't remember how I found it; this was years ago), therefore my code doesn't compile with 2.5b1 (it did OK before with 2.5a2). Is there an alternative spelling for PyRange_New()? You can call PyRange_Type with the appropriate parameters. Georg ___ 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] PyRange_New() alternative?
--- Georg Brandl [EMAIL PROTECTED] wrote: Ralf W. Grosse-Kunstleve wrote: http://docs.python.org/dev/whatsnew/ports.html says: The PyRange_New() function was removed. It was never documented, never used in the core code, and had dangerously lax error checking. I use this function (don't remember how I found it; this was years ago), therefore my code doesn't compile with 2.5b1 (it did OK before with 2.5a2). Is there an alternative spelling for PyRange_New()? You can call PyRange_Type with the appropriate parameters. Thanks a lot for the hint! However, I cannot find any documentation for PyRange_*. I tried this page... http://docs.python.org/api/genindex.html and google. Did I miss something? I am sure I can get this to work with some digging, but I am posting here to highlight a communication problem. I feel if a function is removed the alternative should be made obvious in the associated documentation; in particular if there is no existing documentation for the alternative. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ 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] PyRange_New() alternative?
Ralf W. Grosse-Kunstleve wrote: --- Georg Brandl [EMAIL PROTECTED] wrote: Ralf W. Grosse-Kunstleve wrote: http://docs.python.org/dev/whatsnew/ports.html says: The PyRange_New() function was removed. It was never documented, never used in the core code, and had dangerously lax error checking. I use this function (don't remember how I found it; this was years ago), therefore my code doesn't compile with 2.5b1 (it did OK before with 2.5a2). Is there an alternative spelling for PyRange_New()? You can call PyRange_Type with the appropriate parameters. Thanks a lot for the hint! However, I cannot find any documentation for PyRange_*. I tried this page... http://docs.python.org/api/genindex.html and google. Did I miss something? I am sure I can get this to work with some digging, but I am posting here to highlight a communication problem. I feel if a function is removed the alternative should be made obvious in the associated documentation; in particular if there is no existing documentation for the alternative. Well, PyRange_New *was* undocumented, so there's no place in the documentation where it would have been. However, it would perhaps be helpful to add a note to the whatsnew document for users like yourself. Andrew, does that make sense? Georg ___ 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] PyRange_New() alternative?
On Jun 22, 2006, at 11:55 AM, Ralf W. Grosse-Kunstleve wrote: --- Georg Brandl [EMAIL PROTECTED] wrote: Ralf W. Grosse-Kunstleve wrote: http://docs.python.org/dev/whatsnew/ports.html says: The PyRange_New() function was removed. It was never documented, never used in the core code, and had dangerously lax error checking. I use this function (don't remember how I found it; this was years ago), therefore my code doesn't compile with 2.5b1 (it did OK before with 2.5a2). Is there an alternative spelling for PyRange_New()? You can call PyRange_Type with the appropriate parameters. Thanks a lot for the hint! However, I cannot find any documentation for PyRange_*. I tried this page... http://docs.python.org/api/genindex.html and google. Did I miss something? I am sure I can get this to work with some digging, but I am posting here to highlight a communication problem. I feel if a function is removed the alternative should be made obvious in the associated documentation; in particular if there is no existing documentation for the alternative. He means something like this: PyObject_CallFunction(PyRange_Type, llli, ...) -bob ___ 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] PyRange_New() alternative?
--- Georg Brandl [EMAIL PROTECTED] wrote: Well, PyRange_New *was* undocumented, Yes, that was clear. However, it would perhaps be helpful to add a note to the whatsnew document for users like yourself. Andrew, does that make sense? I am worried about using an alternative that is *again* not documented. There is no mention of PyRange in the Python C API documentation, not even range. Unless I am the only user of PyRange_New() in the whole wide world a few extra lines in the changes document will prevent recurring questions. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ 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] PyRange_New() alternative?
--- Bob Ippolito [EMAIL PROTECTED] wrote: I am sure I can get this to work with some digging, but I am posting here to highlight a communication problem. I feel if a function is removed the alternative should be made obvious in the associated documentation; in particular if there is no existing documentation for the alternative. He means something like this: PyObject_CallFunction(PyRange_Type, llli, ...) Thanks! This does the trick for me: #if PY_VERSION_HEX = 0x0203 PyObject_CallFunction( (PyObject*) PyRange_Type, lll, start, start+len*step, step) #else PyRange_New(start, len, step, 1) #endif I've tested this with Python 2.2.3, 2.3.4, 2.4.3, 2.5b1. Python 2.2.3 (RedHat WS 3) compiles the PyRange_Type call, but there is a runtime error: TypeError: cannot create 'xrange' instances I am compiling the code above with a C++ compiler (in the context of Boost.Python). Newer g++ versions unfortunatly produce a warning if -Wall is specified: warning: dereferencing type-punned pointer will break strict-aliasing rules This refers to the (PyObject*) PyRange_Type cast. I believe the warning is bogus, but people still get upset about it (google the C++-SIG archive). Is there a chance that PyRange_New() could be resurrected, with the fragment above (plus additional overflow check for start+len*step) as the implementation? That would fix the problems of the old implementation, there would be no reason to have the cast in C++, no frustrated end-users, and one change less to document. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ 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
