[PATCH] notify.py: Use a/an correctly when sending request notifications

Eli Schwartz eschwartz at archlinux.org
Fri Aug 9 17:33:17 UTC 2019


On 8/9/19 12:37 PM, Lars Rustand wrote:
> Will no longer send notifications about "a orphan request", but determine
> whether to use a/an based on the first character of the request type.

Thanks, looks like a reasonable change. See below for implementation
nitpicks.

> Signed-off-by: Lars Rustand <rustand.lars at gmail.com>
> ---
>  aurweb/scripts/notify.py | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/aurweb/scripts/notify.py b/aurweb/scripts/notify.py
> index d975086..ace6614 100755
> --- a/aurweb/scripts/notify.py
> +++ b/aurweb/scripts/notify.py
> @@ -414,8 +414,9 @@ class RequestOpenNotification(Notification):
>                     (self._user, self._pkgbase, self._merge_into)
>              body += '\n\n' + self._text
>          else:
> -            body = '%s [1] filed a %s request for %s [2]:' % \
> -                   (self._user, self._reqtype, self._pkgbase)
> +            an = ["a","an"][self._reqtype[0] in "aeiou"]

Using ['a', 'an'][True] as a list index by relying on it equaling the
`1` offset due to implicitly `int(True)` equaling `1` feels pretty
unreadable and I don't think I've ever seen that pattern, what about
instead using a standard ternary operator:

an = 'an' if self._reqtype[0] in 'aeiou' else 'a'

Also: the aurweb codebase generally uses single quotes (and does, for
the surrounding lines), so I think we should stick to that.

> +            body = '%s [1] filed %s %s request for %s [2]:' % \
> +                   (self._user, an, self._reqtype, self._pkgbase)
>              body += '\n\n' + self._text
>          return body
>  
> 


-- 
Eli Schwartz
Bug Wrangler and Trusted User

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1601 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/aur-dev/attachments/20190809/3c8fb906/attachment.sig>


More information about the aur-dev mailing list