[Python-Dev] PEP 553; the interaction between $PYTHONBREAKPOINT and -E (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Wed Oct 4 21:52:25 EDT 2017

On 5 October 2017 at 10:28, Barry Warsaw <barry at python.org> wrote:

"""Special cases aren't special enough to break the rules."""

People expect -E to disable envvar-driven overrides, so just treat it like that and don't try to second-guess the user. And of course "Although practicality beats purity.” :) So while I agree that the consistency argument makes sense, does it make the most practical sense? I’m not sure. On the PR, Nick suggests even another option: treat -E as all other environment variables, but then -I would be PYTHONBREAKPOINT=0. Since the documentation for -I says "(implies -E and -s)” that seems even more special-case-y to me.

-I is inherently a special-case, since it's effectively our "system Python mode", while we don't actually have a separate system Python binary.

Unfortunately we probably won’t really get a good answer in practice until Python 3.7 is released, so maybe I just choose one and document that the behavior of PYTHONBREAKPOINT under -E is provision for now. If that’s acceptable, then I would just treat -E for PYTHONBREAKPOINT the same as all other environment variables, and we’ll see how it goes.

I'd be fine with this as the main reason I wanted PYTHONBREAKPOINT=0 was for pre-merge CI systems, and those tend to have tightly controlled environment settings, so you don't need to rely on -E or -I when running your tests.

That said, it may also be worth considering a "-X nobreakpoints" option (and then -I could imply "-E -s -X nobreakpoints").

Cheers, Nick.

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

More information about the Python-Dev mailing list