Remove unreachable else-block in complex_subtype_from_string in Objects/complexobject.c

[b9788213]

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.

[skirpichev]

See #109642