Skip to content

Commit f521804

Browse files
author
georg.brandl
committed
Patch #1642844: comments to clarify the complexobject constructor.
git-svn-id: http://svn.python.org/projects/python/trunk@54325 6015fed2-1504-0410-9fe1-9d1591cc4771
1 parent c7c9f25 commit f521804

1 file changed

Lines changed: 25 additions & 4 deletions

File tree

Objects/complexobject.c

Lines changed: 25 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -857,12 +857,14 @@ complex_new(PyTypeObject *type, PyObject *args, PyObject *kwds)
857857
&r, &i))
858858
return NULL;
859859

860-
/* Special-case for single argument that is already complex */
860+
/* Special-case for a single argument when type(arg) is complex. */
861861
if (PyComplex_CheckExact(r) && i == NULL &&
862862
type == &PyComplex_Type) {
863863
/* Note that we can't know whether it's safe to return
864864
a complex *subclass* instance as-is, hence the restriction
865-
to exact complexes here. */
865+
to exact complexes here. If either the input or the
866+
output is a complex subclass, it will be handled below
867+
as a non-orthogonal vector. */
866868
Py_INCREF(r);
867869
return r;
868870
}
@@ -913,6 +915,14 @@ complex_new(PyTypeObject *type, PyObject *args, PyObject *kwds)
913915
}
914916
return NULL;
915917
}
918+
919+
/* If we get this far, then the "real" and "imag" parts should
920+
both be treated as numbers, and the constructor should return a
921+
complex number equal to (real + imag*1j).
922+
923+
Note that we do NOT assume the input to already be in canonical
924+
form; the "real" and "imag" parts might themselves be complex
925+
numbers, which slightly complicates the code below. */
916926
if (PyComplex_Check(r)) {
917927
/* Note that if r is of a complex subtype, we're only
918928
retaining its real & imag parts here, and the return
@@ -923,8 +933,14 @@ complex_new(PyTypeObject *type, PyObject *args, PyObject *kwds)
923933
}
924934
}
925935
else {
936+
/* The "real" part really is entirely real, and contributes
937+
nothing in the imaginary direction.
938+
Just treat it as a double. */
939+
cr.imag = 0.0;
926940
tmp = PyNumber_Float(r);
927941
if (own_r) {
942+
/* r was a newly created complex number, rather
943+
than the original "real" argument. */
928944
Py_DECREF(r);
929945
}
930946
if (tmp == NULL)
@@ -937,7 +953,6 @@ complex_new(PyTypeObject *type, PyObject *args, PyObject *kwds)
937953
}
938954
cr.real = PyFloat_AsDouble(tmp);
939955
Py_DECREF(tmp);
940-
cr.imag = 0.0;
941956
}
942957
if (i == NULL) {
943958
ci.real = 0.0;
@@ -946,13 +961,19 @@ complex_new(PyTypeObject *type, PyObject *args, PyObject *kwds)
946961
else if (PyComplex_Check(i))
947962
ci = ((PyComplexObject*)i)->cval;
948963
else {
964+
/* The "imag" part really is entirely imaginary, and
965+
contributes nothing in the real direction.
966+
Just treat it as a double. */
967+
ci.imag = 0.0;
949968
tmp = (*nbi->nb_float)(i);
950969
if (tmp == NULL)
951970
return NULL;
952971
ci.real = PyFloat_AsDouble(tmp);
953972
Py_DECREF(tmp);
954-
ci.imag = 0.;
955973
}
974+
/* If the input was in canonical form, then the "real" and "imag"
975+
parts are real numbers, so that ci.real and cr.imag are zero.
976+
We need this correction in case they were not real numbers. */
956977
cr.real -= ci.imag;
957978
cr.imag += ci.real;
958979
return complex_subtype_from_c_complex(type, cr);

0 commit comments

Comments
 (0)