Hi there,
I'm proposing a new builtin method `b` which is a shorthand for the already-builtin method `breakpoint`. Let me just show you a scratch implementation: (Yes, I am serious)
```
b = breakpoint
```
PEP 553 proposed the builtin method `breakpoint()` (12 characters) as a shorthand for `import pdb; pdb.set_trace()` (27 characters), but it still contains a lot of characters and is easy to typo. Yeah, we have auto-completion to cope with this, but if you are using a full-fledged IDE chances are that it supports inline breakpoints, so you don't need `breakpoint()` or `set_trace()` anyway. The use cases Barry and I are addressing are scenarios where one is forced to use limited toolings, such as fixing a Python helper script shipped with a third-party application, or troubleshooting on a remote/embedded machine.
In interactive workflows like debugging, every keystroke save counts. Think about the shell, where most commands are limited to 4 characters despite the existence of tab-completion. Another good example is gdb/pdb, where common commands have single-character aliases like `s` for `step`. When debugging, the statement `b()` will be inserted and removed more frequently than other functions, so I suppose it deserves the shortest name. I have previously considered `bp()`, but that's 33% longer.
A fair question would be, is it necessary to introduce a Python builtin for this purpose? Sure, one can always do `b = breakpoint`, but just as the same reason `from pdb import set_trace as breakpoint` didn't bring down PEP 553, it's impractical to add `b = breakpoint` at the beginning of each relevant script (how do I even know which scripts are relevant?). The change needs to happen at the core interpreter level to reach all developers and their packages/modules.
To sum up, I think the introduction of a new builtin `b()` will be a big step towards developer ergonomics. What are your thoughts? It is worth drafting a new PEP for this idea?
Bests,
Qingyao
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/6UAJRDKVJNZ7EACXUTUCKSGAEYPJHME5/
Code of Conduct: http://python.org/psf/codeofconduct/