--- 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 >= 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
_______________________________________________
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
