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:
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/


--
--Guido van Rossum (python.org/~guido)
Pronouns: he/him (why is my pronoun here?)