[Python-Dev] PyRange_New() alternative?

[Ralf W. Grosse-Kunstleve]

--- 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:
> PyObject_CallFunction(PyRange_Type, "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