[Python-Dev] PyRange_New() alternative? (original) (raw)

Ralf W. Grosse-Kunstleve rwgk at yahoo.com
Fri Jun 23 07:38:20 CEST 2006

--- Bob Ippolito <bob at redivi.com> 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: PyObjectCallFunction(PyRangeType, "llli", ...)

Thanks! This does the trick for me:

#if PY_VERSION_HEX >= 0x02030000 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

More information about the Python-Dev mailing list