Summary: While performing code coverage analysis (using gcov) on the complex object implementation, I noticed that the else block in complex_subtype_from_string is logically unreachable under the current calling conventions.

Details: The function complex_subtype_from_string(PyTypeObject *type, PyObject *v) contains a check:

if (PyUnicode_Check(v)) {
    // ... logic for unicode ...
}
else {
    PyErr_Format(PyExc_TypeError, "complex() argument must be a string or a number, not %T", v);
    return NULL;
}

However, this function is only called from complex_new in Objects/complexobject.c. In complex_new, there is already a guard clause that ensures complex_subtype_from_string is only invoked if PyUnicode_Check returns true:

if (PyUnicode_Check(arg)) {
    return complex_subtype_from_string(type, arg);
}

Because of this double-check, the else block in complex_subtype_from_string is never executed, even when passing invalid types (like bytes) to a complex subclass. In such cases, the error is handled elsewhere or the function is never reached.

Proposed Change: Since complex_subtype_from_string is a static helper function, we can either:

Remove the else block to clean up the code.

Replace the if (PyUnicode_Check(v)) with an assert(PyUnicode_Check(v)); to maintain safety in debug builds while removing unreachable production code.

Impact:

Slightly cleaner C code.

Improved code coverage metrics.

Removal of redundant type checking.