On 9/6/2017 6:24 PM, Barry Warsaw wrote:
On Sep 6, 2017, at 10:14, Fabio Zadrozny <fabi...@gmail.com> wrote:
I think it's a nice idea.
Great!
Related to the name, on the windows c++ there's "DebugBreak":
https://msdn.microsoft.com/en-us/library/windows/desktop/ms679297(v=vs.85).aspx, which I
think is a better name (so, it'd be debug_break for Python -- I think it's better than
plain breakpoint(), and wouldn't clash as debug()).
It’s important to understand that a new built-in is technically never going to
clash with existing code, regardless of what it’s called. Given Python’s name
resolution rules, if your code uses any built, it’ll just shadow it. That’s
one big reason why the PEP proposed a built-in rather than say a keyword.
That said, while I like the more succinct `debug()` name, Guido prefers
`breakpoint()` and that works fine for me.
I think I could change the hook on a custom sitecustomize (there's already one
in place in PyDev) so that the debug_break() would actually read some env var
to do that work (and provide some utility for users to pre-setup it when not
launching from inside the IDE).
I had meant to add an open issue about the idea of adding an environment
variable, such as $PYTHONBREAKPOINTHOOK which could be set to the callable to
bind to sys.breakpointhook().
Environmental variables are set to strings, not objects. It is not
clear how you intend to handle the conversion.
--
Terry Jan Reedy
_______________________________________________
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
