On Mon, Sep 11, 2017 at 5:27 PM, Barry Warsaw <ba...@python.org> wrote: > On Sep 10, 2017, at 13:46, Nathaniel Smith <n...@pobox.com> wrote: >> >> On Sun, Sep 10, 2017 at 12:06 PM, Barry Warsaw <ba...@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 _______________________________________________ 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
