public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Kevin Buettner <kevinb@redhat.com>
Cc: gdb-patches@sourceware.org, pedro@palves.net, simark@simark.ca
Subject: Re: [PATCH] set/show python dont-write-bytecode fixes
Date: Sat, 23 Jul 2022 09:54:33 +0300	[thread overview]
Message-ID: <83y1wkiaja.fsf@gnu.org> (raw)
In-Reply-To: <20220722183722.57d34c34@f35-zws-1> (message from Kevin Buettner on Fri, 22 Jul 2022 18:37:22 -0700)

> Date: Fri, 22 Jul 2022 18:37:22 -0700
> From: Kevin Buettner <kevinb@redhat.com>
> Cc: gdb-patches@sourceware.org, pedro@palves.net, simark@simark.ca
> 
> > > +In order to take effect, this setting must be enabled before python\n\
> > > +initialization."),  
> >
> > Will GDB users understand clearly what that means in practical terms?
> 
> The GDB manual contains similar (though not identical) wording.  I
> referenced the manual while writing the help text.  However, the
> manual does contain additional explanation to help the reader
> understand how to use the command so that it will actually take
> effect.
> 
> > Should we say instead "before invoking the Python interpreter for the
> > first time"?
> 
> We could, but I don't think that your suggested wording is accurate.
> 
> My understanding of things is that in order to effectively use 'set
> python dont-write-bytecode', it must be placed in an early
> initialization file, i.e. those run via the --early-init-eval-command
> or -eix options.  If the command were placed in some other
> initialization file, it might well be run before the embedded Python
> interpreter is run for the first time, yet still not take effect due
> to the command being executed after Python initialization.
> 
> Another way to make sure that the command takes effect is to
> use one of the following options on the GDB command line:
> 
>   --early-init-eval-command 'set python dont-write-bytecode on'
> 
> or:
> 
>   -eiex 'set python dont-write-bytecode on'

Maybe we should say in the doc string that these are the only ways of
changing this setting so it has effect?

> > Finally should we mention the PYTHONDONTWRITEBYTECODE environment
> > variable?
> 
> It is already documented in the GDB manual.  Should it also be
> mentioned in the help text?

That was my question.

> Another fly in the ointment is that the 'python ignore-environment'
> setting also affects how dont-write-bytecode behaves when it's set to
> 'auto'.  If ignore-environment is 'on', then PYTHONDONTWRITEBYTECODE
> is ignored.
> 
> This seems like a lot of detail to place in the help text.

Maybe we should try saying all that, and then decide whether the
resulting text is too long?

> I just noticed that, regarding the "auto" setting, the GDB manual says
> "... in this mode Python will check the environment variable
> PYTHONDONTWRITEBYTECODE to see if it should write out byte-code or
> not."  What it doesn't say is what settings the environment variable
> must have in order to cause byte-code compilation to be suppressed.
> It turns out that any value other than non-existence or the
> empty string will enable the supression of byte-code compilation.
> I.e. using "PYTHONDONTWRITEBYTECODE=no" might not do what the user
> expects.  So, it seems to me that we might update the manual to
> make this clear.  (I can include that in the v2 patch if you agree.)

I agree.  Thanks.

  reply	other threads:[~2022-07-23  6:54 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-20 19:14 Kevin Buettner
2022-07-21 17:55 ` Pedro Alves
2022-07-21 23:08   ` Kevin Buettner
2022-07-22  6:40     ` Eli Zaretskii
2022-07-23  1:37       ` Kevin Buettner
2022-07-23  6:54         ` Eli Zaretskii [this message]
2022-07-23 21:30           ` Kevin Buettner
2022-07-24  5:41             ` Eli Zaretskii

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=83y1wkiaja.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=gdb-patches@sourceware.org \
    --cc=kevinb@redhat.com \
    --cc=pedro@palves.net \
    --cc=simark@simark.ca \
    /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).