[Python-Dev] breakpoint() and $PYTHONBREAKPOINT

[Nathaniel Smith]

On Mon, Sep 11, 2017 at 6:45 PM, Barry Warsaw <barry at python.org> wrote:
> On Sep 11, 2017, at 18:15, Nathaniel Smith <njs at pobox.com> wrote:
>
>> 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;
>
> Maybe, but the effect would be essentially the same as setting sys.breakpointhook during the execution of your program.
>
>> - whether the import happens immediately at startup, or is delayed
>> until the first call to breakpoint().
>
> I definitely think it should be delayed until first use.  You might never hit the breakpoint() in which case you wouldn’t want to pay any penalty for even checking the environment variable.  And once you *do* hit the breakpoint(), you aren’t caring about performance then anyway.
>
> Both points could be addressed by caching the import after the first lookup, but even there I don’t think it’s worth it.  I’d invoke KISS and just look it up anew each time.  That way there’s no global/static state to worry about, and the feature is as flexible as it can be.
>
>> 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().
>
> That’s one case I can see being useful; report an error immediately upon startup rather that when you hit breakpoint().  But even there, I’m not sure.  What if you’ve got some kind of dynamic debugger discovery thing going on, such that the callable isn’t available until its first use?

I don't think that's a big deal? Just do the discovery logic from
inside the callable itself, instead of using some kind of magical
attribute lookup hook.

>> 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?
>
> I’m probably too steeped in the implementation, but it feels to me like not just loading the envar callable on demand makes reasoning about and using this more complicated.  I think for most uses though, it won’t really matter.

I don't mind breaking from convention if you have a good reason, I
just like it for PEPs to actually write down that reasoning :-)

-n

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