[Python-Dev] PEP 553; the interaction between $PYTHONBREAKPOINT and -E
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