From: Victoria Dye <vdye@github.com>
To: dsal3389 via GitGitGadget <gitgitgadget@gmail.com>, git@vger.kernel.org
Cc: dsal3389 <dsal3389@gmail.com>
Subject: Re: [PATCH 1/2] python file more pytonic, adjust "if" and "for"
Date: Thu, 6 Oct 2022 09:02:51 -0700 [thread overview]
Message-ID: <66d1bcaf-64c8-13c2-ba7a-98715de3617b@github.com> (raw)
In-Reply-To: <71da6f53a44cd3390d122ff2c0446824313e5101.1665056747.git.gitgitgadget@gmail.com>
dsal3389 via GitGitGadget wrote:
> From: dsal3389 <dsal3389@gmail.com>
re: the commit message title
s/pytonic/pythonic
Please prefix the title with the file/function being updated. Based on
precedent [1], that'd probably be:
git-p4: <your message>
Also, I'm not sure the reference to "for" is helpful, since you're only
adjusting if-statements in this patch (although one of those conditionals
does include a for-loop, nothing about the loop itself changes).
Finally, please use the imperative mood in your commit messages [2];
something like:
git-p4: adjust "if" statements to be more pythonic
[1] https://lore.kernel.org/git/?q=dfn%3Agit-p4.py
[2] https://git-scm.com/docs/SubmittingPatches#describe-changes
>
> L371
> redesign few lines to get rid of the "else" statement
What was your reason for making this change? I don't see anything in PEP8
[3] regarding this kind of conditional organization being preferred over
what's already there.
For what it's worth, I'm happy with the change itself; I'd just ask that
you include an explanation for why (because it's more concise, or makes the
assignment to 'out' clearer, etc.). The "Describe your changes well" section
of the "SubmittingPatches" document [2] should be a helpful guideline.
Also, as a matter of convention, it's not necessary to include line numbers.
[2] https://git-scm.com/docs/SubmittingPatches#describe-changes
[3] https://peps.python.org/pep-0008/
>
> L404
> moved the if statement below another if statement that
> checks if it should exit the code, only if it doesnt need to,
> then we can iterate the for loop and decode the text
While the actual change below makes sense, I found this explanation very
difficult to parse. Maybe something like:
Reorder if-statements in 'read_pipe_lines()' to raise an error with the
command before trying to decode its results in order to avoid
unnecessary computation.
>
> Changes to be committed:
> modified: git-p4.py
Please remove this text from the commit message.
>
> Signed-off-by: Daniel Sonbolian <dsal3389@gmail.com>
> ---
> git-p4.py | 9 ++++-----
> 1 file changed, 4 insertions(+), 5 deletions(-)
The rest of the implementation looks good, thanks!
>
> diff --git a/git-p4.py b/git-p4.py
> index d26a980e5ac..0ba5115fa2e 100755
> --- a/git-p4.py
> +++ b/git-p4.py
> @@ -368,10 +368,9 @@ def read_pipe(c, ignore_error=False, raw=False, *k, **kw):
> """
> retcode, out, err = read_pipe_full(c, *k, **kw)
> if retcode != 0:
> - if ignore_error:
> - out = ""
> - else:
> + if not ignore_error:
> die('Command failed: {}\nError: {}'.format(' '.join(c), err))
> + out = ""
> if not raw:
> out = decode_text_stream(out)
> return out
> @@ -400,10 +399,10 @@ def read_pipe_lines(c, raw=False, *k, **kw):
> p = subprocess.Popen(c, stdout=subprocess.PIPE, *k, **kw)
> pipe = p.stdout
> lines = pipe.readlines()
> - if not raw:
> - lines = [decode_text_stream(line) for line in lines]
> if pipe.close() or p.wait():
> die('Command failed: {}'.format(' '.join(c)))
> + if not raw:
> + lines = [decode_text_stream(line) for line in lines]
> return lines
>
>
next prev parent reply other threads:[~2022-10-06 16:02 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-06 11:45 [PATCH 0/2] Minor Refactors: remove useless else dsal3389 via GitGitGadget
2022-10-06 11:45 ` [PATCH 1/2] python file more pytonic, adjust "if" and "for" dsal3389 via GitGitGadget
2022-10-06 16:02 ` Victoria Dye [this message]
2022-10-06 17:16 ` Junio C Hamano
2022-10-06 11:45 ` [PATCH 2/2] removed else statement dsal3389 via GitGitGadget
2022-10-06 16:14 ` Victoria Dye
2022-10-07 18:35 ` Junio C Hamano
2022-10-06 17:16 ` Junio C Hamano
2022-10-06 17:06 ` [PATCH 0/2] Minor Refactors: remove useless else Junio C Hamano
2022-10-07 14:38 ` [PATCH v2 0/2] git.c: improve readability | git-p4: minor optimization Daniel Sonbolian via GitGitGadget
2022-10-07 14:38 ` [PATCH v2 1/2] git-p4: minor optimization in read_pip_lines Daniel Sonbolian via GitGitGadget
2022-10-07 15:17 ` Phillip Wood
2022-10-07 17:28 ` Junio C Hamano
2022-10-07 14:38 ` [PATCH v2 2/2] git.c: improve code readability in cmd_main Daniel Sonbolian via GitGitGadget
2022-10-08 16:21 ` [PATCH v3] " Daniel Sonbolian via GitGitGadget
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=66d1bcaf-64c8-13c2-ba7a-98715de3617b@github.com \
--to=vdye@github.com \
--cc=dsal3389@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.