public inbox for newlib@sourceware.org
 help / color / mirror / Atom feed
From: Mike Frysinger <vapier@gentoo.org>
To: Jon Turney <jon.turney@dronecode.org.uk>
Cc: "newlib@sourceware.org" <newlib@sourceware.org>
Subject: Re: [PATCH] makedocbook: Fix false report of unhandled texinfo command
Date: Fri, 4 Nov 2022 22:13:20 +0700	[thread overview]
Message-ID: <Y2UsEKBU+9tdBTsL@vapier> (raw)
In-Reply-To: <9b242eca-08ba-cc4f-fc2c-b8ad72992c37@dronecode.org.uk>

[-- Attachment #1: Type: text/plain, Size: 2648 bytes --]

On 04 Nov 2022 13:50, Jon Turney wrote:
> On 31/10/2022 12:28, Mike Frysinger wrote:
> > On 31 Oct 2022 09:59, Jon Turney wrote:
> >> +    if match:
> >> +        print("texinfo command '%s' remains in output" % match.group(), file=sys.stderr)
> > 
> > this is a little dangerous in general as match.group() could return a tuple,
> > and this would fail.  if you want to use %, you should force a tuple.
> >    print("..." % (match.group(),), ...)
> 
> I must be missing something here, because I'm not sure in what sense 
> 'could' is being used. I think match.group() is defined to be the same 
> as match.group(0), which always returns a single string. (I guess this 
> could be written explicitly).

you are correct that match.group() is match.group(0) which guarantees to
return a string.  when i wrote this, i didn't have access to the python
manual, so i checked against help() in the python repl.  the docs there
are much more terse and don't include the situations as to when a str or
a tuple would be returned.

> So the danger pointed out seems to be that if parts of the code were 
> changed, without making other necessary changes, it would be wrong. But 
> I'm not sure the suggested change just to avoid that future possibility 
> makes things better or clearer.

i've been bitten by refactors breaking % usage that lacks test coverage
(which, practically speaking, i think you could say most of the python
code here lacks unittests, especially in error code paths), so i have an
allergy to code that uses % without guaranteeing somehow that a tuple is
being passed like this code is doing now.

i grok that `% foo` vs `% (foo,)` looks a bit funky when you aren't used
to it, but i think this is more of a muscle memory thing -- this is the
only way to write a single element tuple.

i would have suggested using a f-string, but i don't know what versions
of python you want to support as f-strings require Python 3.6+.

of course if you really want to use % with a single element, i think it's
wrong, but i'm not going to make a continued stink about it :p.

> >> +        exit(1)
> > 
> > scripts should never use exit(), only sys.exit().  although i see the current
> > script gets this wrong in a lot of places.
> > 
> > also you can simplify this -- sys.exit accepts a string that it'll print to
> > stderr and then exit non-zero.
> >    sys.exit(".....")
> 
> Yes, this is one of the first things I wrote in python, and 
> unfortunately, it shows.

i wrote python like a C programmer for quite a long time,
and it took a while to reform my brain for python idioms
-mike

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

      reply	other threads:[~2022-11-04 15:13 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-31  9:59 Jon Turney
2022-10-31 12:28 ` Mike Frysinger
2022-11-04 13:50   ` Jon Turney
2022-11-04 15:13     ` Mike Frysinger [this message]

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=Y2UsEKBU+9tdBTsL@vapier \
    --to=vapier@gentoo.org \
    --cc=jon.turney@dronecode.org.uk \
    --cc=newlib@sourceware.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).