[Python-Dev] breakpoint() and $PYTHONBREAKPOINT

Nick Coghlan ncoghlan at gmail.com
Tue Sep 12 06:28:24 EDT 2017


On 12 September 2017 at 11:15, Nathaniel Smith <njs at pobox.com> wrote:
> 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.

I think this case is closer to PYTHONINSPECT than it is to PYTHONPATH,
and we *do* delay checking PYTHONINSPECT until the application is
shutting down specifically so programs can set the env var during
execution.

> - 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?

This is independent of whether the check happens in the builtin or in
the default hook, and I agree with Barry that it should be queried
lazily regardless of whether it's the builtin or the default hook that
checks it.

I think it would be reasonable for the default hook to cache the
result of PYTHONBREAKPOINT on the first lookup and then not check it
again on future calls, though.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Python-Dev mailing list