[Python-Dev] breakpoint() and $PYTHONBREAKPOINT

[Nathaniel Smith]

On Mon, Sep 11, 2017 at 5:27 PM, Barry Warsaw <barry at python.org> wrote:
> On Sep 10, 2017, at 13:46, Nathaniel Smith <njs at pobox.com> wrote:
>>
>> On Sun, Sep 10, 2017 at 12:06 PM, Barry Warsaw <barry at python.org> wrote:
>>> For PEP 553, I think it’s a good idea to support the environment variable $PYTHONBREAKPOINT[*] but I’m stuck on a design question, so I’d like to get some feedback.
>>>
>>> Should $PYTHONBREAKPOINT be consulted in breakpoint() or in sys.breakpointhook()?
>>
>> Wouldn't the usual pattern be to check $PYTHONBREAKPOINT once at
>> startup, and if it's set use it to initialize sys.breakpointhook()?
>> Compare to, say, $PYTHONPATH.
>
> Perhaps, but what would be the visible effects of that?  I.e. what would that buy you?

Why is this case special enough to break the rules?

Compared to checking it on each call to sys.breakpointhook(), I guess
the two user-visible differences in behavior would be:

- whether mutating os.environ["PYTHONBREAKPOINT"] inside the process
affects future calls. I would find it quite surprising if it did;
generally when we mutate envvars like os.environ["PYTHONPATH"] it's a
way to set things up for future child processes and doesn't affect our
process.

- whether the import happens immediately at startup, or is delayed
until the first call to breakpoint(). If it's imported once at
startup, then this adds overhead to programs that set PYTHONBREAKPOINT
but don't use it, and if the envvar is set to some nonsense then you
get an error immediately instead of at the first call to breakpoint().
These both seem like fairly minor differences to me, but maybe saving
that 30 ms or whatever of startup time is an important enough
optimization to justify the special case?

-n

-- 
Nathaniel J. Smith -- https://vorpus.org