On 5 October 2017 at 10:28, Barry Warsaw <ba...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ 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
