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-le...@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?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/QKBIROJKCO3A27TJRVJFONHHDPUKQAHN/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to