Well that also makes sense. On Wed, Oct 4, 2017 at 1:52 PM, Antoine Pitrou wrote:

On Wed, 4 Oct 2017 14:06:48 -0400 Barry Warsaw wrote:

...

Victor brings up a good question in his review of the PEP 553 implementation.

https://github.com/python/cpython/pull/3355 https://bugs.python.org/issue31353

The question is whether $PYTHONBREAKPOINT should be ignored if -E is given?

I think it makes sense for $PYTHONBREAKPOINT to be sensitive to -E, but in thinking about it some more, it might make better sense for the semantics to be that when -E is given, we treat it like PYTHONBREAKPOINT=0, i.e. disable the breakpoint, rather than fallback to the `pdb.set_trace` default.

"""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.

Regards

Antoine.

_______________________________________________ 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/ guido%40python.org

-- --Guido van Rossum (python.org/~guido)

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

I concur with Antoine, please don't add a special case for -E. But it seems like you already agreed with that :-) Victor Le 5 oct. 2017 05:33, "Barry Warsaw" a écrit :

On Oct 4, 2017, at 21:52, Nick Coghlan wrote:

...

...

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").

Thanks for the feedback Nick. For now we’ll go with the standard behavior of -E and see how it goes. We can always add a -X later.

Cheers, -Barry

_______________________________________________ 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/ victor.stinner%40gmail.com

What if make the default value depending on the debug level? In debug mode it is "pdb.set_trace", in optimized mode it is "0". Then in production environments you can use -E -O for ignoring environment settings and disable breakpoints.

I don't know what is the best option, but I dislike adding two options, PYTHONBREAKPOINT and -X nobreakpoint, for the same features. I would become complicated to know which option has the priority. I would prefer a generic "release mode" option. In the past, I proposed the opposite: a "developer mode": https://mail.python.org/pipermail/python-ideas/2016-March/039314.html "python3 -X dev" would be an "alias" to "PYTHONMALLOC=debug python3.6 -Wd -bb -X faulthandler script.py". Python has more and more options to enable debug checks at runtime, it's hard to be aware of all of them. My intent is to run tests in "developer mode": if tests pass, you are sure that they will pass in the regular mode since the developer mode only enables more checks at runtime, it shouldn't change the behaviour. It seems like the consensus is more to run Python in "release mode" by default, since it was decided to hide DeprecationWarning by default. I understood that the default mode targets end users. Victor