> """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. "In the face of ambiguity, refuse the temptation to guess.” I’m really not sure what the right answer is, including to *not* make PYTHONBREAKPOINT obey -E. 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. Cheers, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: <http://mail.python.org/pipermail/python-dev/attachments/20171004/542b9826/attachment.sig>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4