René's URL Explorer Experiment

Title: Don't return with operand when conceptually void by EliahKagan · Pull Request #1755 · gitpython-developers/GitPython · GitHub

Open Graph Title: Don't return with operand when conceptually void by EliahKagan · Pull Request #1755 · gitpython-developers/GitPython

X Title: Don't return with operand when conceptually void by EliahKagan · Pull Request #1755 · gitpython-developers/GitPython

Description: This changes return None to return where it appears in functions that are "conceptually void," i.e. cases where a function always returns None, its purpose is never to provide a return value to the caller, and it would be a bug (or at least confusing style) to use the return value or have the call as a subexpression. This is already the prevailing style, so this is a consistency improvement, as well as improving clarity by avoiding giving the impression that "None" is significant in those cases. Of course, functions that sometimes return values other than None do not have return None replaced with a bare return statement. Those are left alone (when they return None, it means something). For the most part this is straightforward, but: The handle_stderr local function in IndexFile.checkout is also slightly further refactored to better express what the early return is doing. Because it is a local function, the diff in the "Files Changed" tab of this pull request makes it look like it is in the checkout method, where such a change would not be correct. Instead, that is the enclosing scope, and it is in a nested function where the change does make sense. The None operand is removed as usual in GitConfigParser.read, even though a superclass has a same-named method with a return type that is not None. Usually when this happens, the superclass method returns something like Optional[Something], and it is a case of return-type covariance, in which case the None operands should still be written. Here, however, the overriding method does not intend to be an override: it has an incompatible signature and cannot be called as if it were the superclass method, nor is its return type compatible. The None operand is retained in the code at the very end of git.cmd.handle_process_output, even though the return type is annotated as None, because the function also returns the expression finalizer(process). The argument finalizer is itself annotated to return None, but it looks like the intent may be to play along with the strange case that finalizer returns a non-None value, and forward it: GitPython/git/cmd.py Lines 207 to 210 in b8ee9be if finalizer: return finalizer(process) else: return None So changing return None to return doesn't make sense there. But depending on intent, maybe it should be just: if finalizer: finalizer(process) I noticed after #1754, which made changes to Git.AutoInterrupt._terminate, was approved, that I had should have fixed how it used return in some places and return None in others. So I looked for return None that should be return throughout the project to see what else to fix along with it, resulting in this PR.

Open Graph Description: This changes return None to return where it appears in functions that are "conceptually void," i.e. cases where a function always returns None, its purpose is never to provide a return va...

X Description: This changes return None to return where it appears in functions that are "conceptually void," i.e. cases where a function always returns None, its purpose is never to provide a r...

Opengraph URL: https://github.com/gitpython-developers/GitPython/pull/1755

X: @github

direct link

Domain: github.com

Links:

Viewport: width=device-width