RetroSearch Browse

Wed Oct 4 21:52:25 EDT 2017 · https://mail.python.org/pipermail/python-dev/2017-October/149772.html

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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2017-October/149772.html below:

[Python-Dev] PEP 553; the interaction between $PYTHONBREAKPOINT and -E