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
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
--- 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,
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
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
--- 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
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
--- 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
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
--- 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
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
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,
--- 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
--- 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
14 matches
Mail list logo
