complex() was the only numeric constructor that created a new instance
when given its own type as an argument.
This commit is contained in:
parent
18bd11205d
commit
604cd6ae79
|
@ -140,6 +140,10 @@ if complex(0.0, 3.14) != 3.14j: raise TestFailed, 'complex(0.0, 3.14)'
|
|||
if complex("1") != 1+0j: raise TestFailed, 'complex("1")'
|
||||
if complex("1j") != 1j: raise TestFailed, 'complex("1j")'
|
||||
|
||||
c = 3.14 + 1j
|
||||
if complex(c) is not c: raise TestFailed, 'complex(3.14+1j) changed identity'
|
||||
del c
|
||||
|
||||
try: complex("1", "1")
|
||||
except TypeError: pass
|
||||
else: raise TestFailed, 'complex("1", "1")'
|
||||
|
|
|
@ -823,6 +823,15 @@ complex_new(PyTypeObject *type, PyObject *args, PyObject *kwds)
|
|||
if (!PyArg_ParseTupleAndKeywords(args, kwds, "|OO:complex", kwlist,
|
||||
&r, &i))
|
||||
return NULL;
|
||||
|
||||
/* Special-case for single argumet that is already complex */
|
||||
if (PyComplex_CheckExact(r) && i == NULL) {
|
||||
/* Note that we can't know whether it's safe to return
|
||||
a complex *subclass* instance as-is, hence the restriction
|
||||
to exact complexes here. */
|
||||
Py_INCREF(r);
|
||||
return r;
|
||||
}
|
||||
if (PyString_Check(r) || PyUnicode_Check(r)) {
|
||||
if (i != NULL) {
|
||||
PyErr_SetString(PyExc_TypeError,
|
||||
|
|
Loading…
Reference in New Issue