On Mon, Sep 11, 2017 at 6:45 PM, Barry Warsaw <ba...@python.org> wrote: > On Sep 11, 2017, at 18:15, Nathaniel Smith <n...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
