[Python-Dev] PyRange_New() alternative?
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:
> PyObject_CallFunction(PyRange_Type, "llli", ...)
Thanks! This does the trick for me:
#if PY_VERSION_HEX >= 0x02030000
(PyObject*) &PyRange_Type, "lll", start, start+len*step, step)
PyRange_New(start, len, step, 1)
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
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
More information about the Python-Dev