Allow core Python build to succeed under WITHOUT_COMPLEX. The module build stage still fails.

This commit is contained in:
Mark Dickinson 2009-10-15 17:45:39 +00:00
parent 08133af12e
commit 026ac7cf69
2 changed files with 9 additions and 4 deletions

View File

@ -910,10 +910,8 @@ compiler_add_o(struct compiler *c, PyObject *dict, PyObject *o)
{
PyObject *t, *v;
Py_ssize_t arg;
unsigned char *p, *q;
Py_complex z;
unsigned char *p;
double d;
int real_part_zero, imag_part_zero;
/* necessary to make sure types aren't coerced (e.g., int and long) */
/* _and_ to distinguish 0.0 from -0.0 e.g. on IEEE platforms */
@ -928,7 +926,11 @@ compiler_add_o(struct compiler *c, PyObject *dict, PyObject *o)
else
t = PyTuple_Pack(2, o, o->ob_type);
}
#ifndef WITHOUT_COMPLEX
else if (PyComplex_Check(o)) {
Py_complex z;
int real_part_zero, imag_part_zero;
unsigned char *q;
/* complex case is even messier: we need to make complex(x,
0.) different from complex(x, -0.) and complex(0., y)
different from complex(-0., y), for any x and y. In
@ -958,6 +960,7 @@ compiler_add_o(struct compiler *c, PyObject *dict, PyObject *o)
t = PyTuple_Pack(2, o, o->ob_type);
}
}
#endif /* WITHOUT_COMPLEX */
else {
t = PyTuple_Pack(2, o, o->ob_type);
}

View File

@ -1,7 +1,7 @@
/***********************************************************************/
/* Implements the string (as opposed to unicode) version of the
built-in formatters for string, int, float. That is, the versions
of int.__float__, etc., that take and return string objects */
of int.__format__, etc., that take and return string objects */
#include "Python.h"
#include "../Objects/stringlib/stringdefs.h"
@ -10,6 +10,8 @@
#define FORMAT_LONG _PyLong_FormatAdvanced
#define FORMAT_INT _PyInt_FormatAdvanced
#define FORMAT_FLOAT _PyFloat_FormatAdvanced
#ifndef WITHOUT_COMPLEX
#define FORMAT_COMPLEX _PyComplex_FormatAdvanced
#endif
#include "../Objects/stringlib/formatter.h"