I believe that the original intent of the code is that `_exec_command_python` be used exactly when we *don't* have usable file descriptors, because `_exec_command` requires usable file descriptors. So the `== -1` check is a check for whether sys.stdout's fileno is *bad*. I don't know why `sys.stdout.fileno()` would return -1, but assuming that this can happen in some case, then it would indicate that the fileno is not usable, so probably the closest match to the original code would be to add
```
if r == -1:
    return False
```
inside `_supports_fileno`, and then make this
```
if (_with_python and (not _supports_fileno(sys.stdout) or not _supports_fileno(sys.stderr)):
    ...
```

OTOH we have just made it so that `_exec_command` actually *does* work even if `sys.stdout`/`sys.stderr` don't have working file descriptors, so probably `_exec_command_python` should just never be used. Which is, I think, what happens now, because `sys.stdout.fileno()` never actually returns -1 in any of the environments where people actually use this.

I'm not sure what the right trade-off is between fixing this code 'properly' (which would probably mean, burning it and just using `subprocess` instead), and making a minimal hack to keep things working while minimally disturbing whatever rickety code is built on top of this.

I guess the best solution is probably:
* Add a check for `r == -1` to `_supports_fileno` -- who knows, maybe someone needs it, and certainly -1 is not a valid file descriptor.
* Dike out the call to `_exec_command_python` entirely; I guess just by deleting this branch of the `if`.