[RFC] Built-in shorthand b() for breakpoint()
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
This sounds like a bad idea, since 'b' is a common variable name (like all short names are) and people would fall in the trap of forgetting that there's a variable named 'b' in scope when they call 'b()'. If you're having trouble typing 'breakpoint' maybe you can switch to an editor that has some form of code completion. Or you can use the 'b = breakpoint' trick yourself at the top of your file. On Wed, Dec 2, 2020 at 8:06 AM Qingyao Sun via Python-ideas < python-ideas@python.org> wrote:
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...>
since 'b' is a common variable name (like all short names are) and people would fall in the trap of forgetting that
Thanks for the reply! there's a variable named 'b' in scope when they call 'b()'. That's a good point. I should have seen this issue myself. I have an alternative proposal to address this. What about `_ = breakpoint` instead? While `_` is still a short name, the only logical place a variable will be named as such is inside a for-loop to capture unused values, which I don't think is common enough to render the shorthand useless. In case there is a name collision, we can make a special error message pointing people to `breakpoint`. People are not expected to use a variable named `_` anyway.
I have explained why these two workarounds cannot solve the issue in my original post. Could you re-read it? To paraphrase, this shorthand is for developers who are not a frequent user of pdb due to its unergonomic name, and there are cases where you don't have access to decent code completion (and having to switch to another editor is never comfortable). From my understanding, the major contribution of PEP 553 is that it makes the debugger more accessible by replacing the 27-character command sequence `import pdb; pdb.set_trace()` with the 12-character `breakpoint()`. I want to take it one step further because 12 characters is still unnecessary wordy. Qingyao
See https://docs.python.org/3/library/gettext.html. '_' is the standard name for i18n conversion. I am against any more standard renaming of breakpoint(). If someone wants to bind that to another name, they are free to. The point isn't the length, but the memorability of the name. On Wed, Dec 2, 2020 at 11:18 PM Qingyao Sun via Python-ideas < python-ideas@python.org> wrote:
-- The dead increasingly dominate and strangle both the living and the not-yet born. Vampiric capital and undead corporate persons abuse the lives and control the thoughts of homo faber. Ideas, once born, become abortifacients against new conceptions.
Single-letter variables are common. If your use-case is inserting breakpoints into arbitrary library code there's no way to guarantee that the builtin won't be shadowed by some arguments or other local variables, making your alias extremely unreliable. def add(a, b): """Arbitrary library code.""" b() # This will fail because the argument shadows the builtin return a + b Sure you could argue that the `breakpoint` builtin is affected by shadowing too, but it's much less common to have a variable named `breakpoint` than `b`. I think an even worse consequence would be the cryptic error message that beginners would be likely to encounter in programming tutorials. Quick example: def add(a): # Assuming some kind of tutorial about functions return a + b NameError: name 'b' is not defined Let's imagine that the beginner made a mistake and forgot to declare the second argument. The error message is clear, but with your `breakpoint` alias this is what the interpreter will print out: TypeError: unsupported operand type(s) for +: 'int' and 'builtin_function_or_method' Really confusing. I highly oppose this.
This sounds like a bad idea, since 'b' is a common variable name (like all short names are) and people would fall in the trap of forgetting that there's a variable named 'b' in scope when they call 'b()'. If you're having trouble typing 'breakpoint' maybe you can switch to an editor that has some form of code completion. Or you can use the 'b = breakpoint' trick yourself at the top of your file. On Wed, Dec 2, 2020 at 8:06 AM Qingyao Sun via Python-ideas < python-ideas@python.org> wrote:
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...>
since 'b' is a common variable name (like all short names are) and people would fall in the trap of forgetting that
Thanks for the reply! there's a variable named 'b' in scope when they call 'b()'. That's a good point. I should have seen this issue myself. I have an alternative proposal to address this. What about `_ = breakpoint` instead? While `_` is still a short name, the only logical place a variable will be named as such is inside a for-loop to capture unused values, which I don't think is common enough to render the shorthand useless. In case there is a name collision, we can make a special error message pointing people to `breakpoint`. People are not expected to use a variable named `_` anyway.
I have explained why these two workarounds cannot solve the issue in my original post. Could you re-read it? To paraphrase, this shorthand is for developers who are not a frequent user of pdb due to its unergonomic name, and there are cases where you don't have access to decent code completion (and having to switch to another editor is never comfortable). From my understanding, the major contribution of PEP 553 is that it makes the debugger more accessible by replacing the 27-character command sequence `import pdb; pdb.set_trace()` with the 12-character `breakpoint()`. I want to take it one step further because 12 characters is still unnecessary wordy. Qingyao
See https://docs.python.org/3/library/gettext.html. '_' is the standard name for i18n conversion. I am against any more standard renaming of breakpoint(). If someone wants to bind that to another name, they are free to. The point isn't the length, but the memorability of the name. On Wed, Dec 2, 2020 at 11:18 PM Qingyao Sun via Python-ideas < python-ideas@python.org> wrote:
-- The dead increasingly dominate and strangle both the living and the not-yet born. Vampiric capital and undead corporate persons abuse the lives and control the thoughts of homo faber. Ideas, once born, become abortifacients against new conceptions.
Single-letter variables are common. If your use-case is inserting breakpoints into arbitrary library code there's no way to guarantee that the builtin won't be shadowed by some arguments or other local variables, making your alias extremely unreliable. def add(a, b): """Arbitrary library code.""" b() # This will fail because the argument shadows the builtin return a + b Sure you could argue that the `breakpoint` builtin is affected by shadowing too, but it's much less common to have a variable named `breakpoint` than `b`. I think an even worse consequence would be the cryptic error message that beginners would be likely to encounter in programming tutorials. Quick example: def add(a): # Assuming some kind of tutorial about functions return a + b NameError: name 'b' is not defined Let's imagine that the beginner made a mistake and forgot to declare the second argument. The error message is clear, but with your `breakpoint` alias this is what the interpreter will print out: TypeError: unsupported operand type(s) for +: 'int' and 'builtin_function_or_method' Really confusing. I highly oppose this.
participants (4)
-
David Mertz -
Guido van Rossum -
sunqingyao19970825＠icloud.com -
Valentin Berlier