Re: [Python-Dev] PEP 553

apologies - I didn't "reply all" to this. For the record: I made an argument (in reply) about interactive tinkering, and setting "condition", and Guido replied essentially that "if condition: breakpoint()" is just as good for tinkering... a condition parameter to debuggers is not useful, and not

Re: [Python-Dev] PEP 553; the interaction between $PYTHONBREAKPOINT and -E

> I don't know what is the best option, but I dislike adding two > options, PYTHONBREAKPOINT and -X nobreakpoint, for the same features. > I would become complicated to know which option has the priority. Just to close the loop, I’ve landed the PEP 553 PR treating PYTHONBREAKPOINT the same as

Re: [Python-Dev] PEP 553; the interaction between $PYTHONBREAKPOINT and -E

> What if make the default value depending on the debug level? In debug mode > it is "pdb.set_trace", in optimized mode it is "0". Then in production > environments you can use -E -O for ignoring environment settings and disable > breakpoints. I don't know what is the best option, but I dislike

Re: [Python-Dev] PEP 553; the interaction between $PYTHONBREAKPOINT and -E

04.10.17 21:06, Barry Warsaw пише: Victor brings up a good question in his review of the PEP 553 implementation. https://github.com/python/cpython/pull/3355 https://bugs.python.org/issue31353 The question is whether $PYTHONBREAKPOINT should be ignored if -E is given? I think it makes sense

Re: [Python-Dev] PEP 553; the interaction between $PYTHONBREAKPOINT and -E

I concur with Antoine, please don't add a special case for -E. But it seems like you already agreed with that :-) Victor Le 5 oct. 2017 05:33, "Barry Warsaw" a écrit : > On Oct 4, 2017, at 21:52, Nick Coghlan wrote: > > > >> Unfortunately we probably

Re: [Python-Dev] PEP 553; the interaction between $PYTHONBREAKPOINT and -E

On Oct 4, 2017, at 21:52, Nick Coghlan wrote: > >> Unfortunately we probably won’t really get a good answer in practice until >> Python 3.7 is released, so maybe I just choose one and document that the >> behavior of PYTHONBREAKPOINT under -E is provision for now. If

Re: [Python-Dev] PEP 553

Yarko, there's one thing I don't understand. Maybe you can enlighten me. Why would you prefer breakpoint(x >= 1000) over if x >= 1000: breakpoint() ? The latter seems unambiguous and requires thinking all around. Is there something in iPython that makes this impractical? -- --Guido van

Re: [Python-Dev] PEP 553; the interaction between $PYTHONBREAKPOINT and -E

On 5 October 2017 at 10:28, Barry Warsaw wrote: >> """Special cases aren't special enough to break the rules.""" >> >> People expect -E to disable envvar-driven overrides, so just treat it >> like that and don't try to second-guess the user. > > And of course "Although

Re: [Python-Dev] PEP 553

On Wed, Oct 4, 2017 at 7:50 PM, Barry Warsaw wrote: > On Oct 4, 2017, at 20:22, Yarko Tymciurak wrote: > > > I've recently started using a simple conditional breakpoint in ipython, > and wonder if - in addition to Nick Coghlan's request for the env >

Re: [Python-Dev] PEP 553

On 10/4/2017 5:22 PM, Yarko Tymciurak wrote: Barry suggested I bring this up here. It seems the right time to at least discuss this: RE:  PEP 553 enabling / disabling breakpoints --- I've recently started using a simple conditional breakpoint in ipython, and wonder if  - in addition to Nick

Re: [Python-Dev] PEP 553

On Oct 4, 2017, at 20:22, Yarko Tymciurak wrote: > I've recently started using a simple conditional breakpoint in ipython, and > wonder if - in addition to Nick Coghlan's request for the env > 'PYTHONBREAKPOINT' (boolean?), it would make sense (I _think_ so) to add a >

Re: [Python-Dev] PEP 553; the interaction between $PYTHONBREAKPOINT and -E

> """Special cases aren't special enough to break the rules.""" > > People expect -E to disable envvar-driven overrides, so just treat it > like that and don't try to second-guess the user. And of course "Although practicality beats purity.” :) So while I agree that the consistency argument

Re: [Python-Dev] PEP 553

Barry suggested I bring this up here. It seems the right time to at least discuss this: RE: PEP 553 enabling / disabling breakpoints --- I've recently started using a simple conditional breakpoint in ipython, and wonder if - in addition to Nick Coghlan's request for the env 'PYTHONBREAKPOINT'

Re: [Python-Dev] PEP 553; the interaction between $PYTHONBREAKPOINT and -E

Well that also makes sense. On Wed, Oct 4, 2017 at 1:52 PM, Antoine Pitrou wrote: > On Wed, 4 Oct 2017 14:06:48 -0400 > Barry Warsaw wrote: > > Victor brings up a good question in his review of the PEP 553 > implementation. > > > >

Re: [Python-Dev] PEP 553; the interaction between $PYTHONBREAKPOINT and -E

On Wed, 4 Oct 2017 14:06:48 -0400 Barry Warsaw wrote: > Victor brings up a good question in his review of the PEP 553 implementation. > > https://github.com/python/cpython/pull/3355 > https://bugs.python.org/issue31353 > > The question is whether $PYTHONBREAKPOINT should be

Re: [Python-Dev] PEP 553; the interaction between $PYTHONBREAKPOINT and -E

Treating -E as PYTHONBREAKPOINT=0 makes sense. On Wed, Oct 4, 2017 at 11:06 AM, Barry Warsaw wrote: > Victor brings up a good question in his review of the PEP 553 > implementation. > > https://github.com/python/cpython/pull/3355 > https://bugs.python.org/issue31353 > > The

[Python-Dev] PEP 553; the interaction between $PYTHONBREAKPOINT and -E

Victor brings up a good question in his review of the PEP 553 implementation. https://github.com/python/cpython/pull/3355 https://bugs.python.org/issue31353 The question is whether $PYTHONBREAKPOINT should be ignored if -E is given? I think it makes sense for $PYTHONBREAKPOINT to be sensitive

Re: [Python-Dev] PEP 553

On Oct 2, 2017, at 18:43, Guido van Rossum wrote: > > OK. That then concludes the review of your PEP. It is now accepted! Congrats. > I am looking forward to using the backport. :-) Yay, thanks! We’ll see if I can sneak that backport past Ned. :) -Barry signature.asc

Re: [Python-Dev] PEP 553

On Mon, Oct 2, 2017 at 3:03 PM, Barry Warsaw wrote: > On Oct 2, 2017, at 17:36, Guido van Rossum wrote: > > > I've seen your updates and it is now acceptable, except for *one* nit: > in builtins.breakpoint() the pseudo code raises RuntimeError if >

Re: [Python-Dev] PEP 553

On Oct 2, 2017, at 17:36, Guido van Rossum wrote: > I've seen your updates and it is now acceptable, except for *one* nit: in > builtins.breakpoint() the pseudo code raises RuntimeError if > sys.breakpointhook is missing or None. OTOH sys.breakpointhook() just issues > a

Re: [Python-Dev] PEP 553

On Mon, Oct 2, 2017 at 11:02 AM, Barry Warsaw wrote: > Thanks for the review Guido! The PEP and implementation have been updated > to address your comments, but let me briefly respond here. > > > On Oct 2, 2017, at 00:44, Guido van Rossum wrote: > > > -

Re: [Python-Dev] PEP 553

On 10/2/2017 10:45 AM, Guido van Rossum wrote: On Sun, Oct 1, 2017 at 11:15 PM, Terry Reedy > wrote: On 10/2/2017 12:44 AM, Guido van Rossum wrote: - There's no rationale for the *args, **kwds part of the breakpoint() signature.

Re: [Python-Dev] PEP 553

Thanks for the review Guido! The PEP and implementation have been updated to address your comments, but let me briefly respond here. > On Oct 2, 2017, at 00:44, Guido van Rossum wrote: > - There's a comma instead of a period at the end of the 4th bullet in the > Rationale:

Re: [Python-Dev] PEP 553

On Sun, Oct 1, 2017 at 11:15 PM, Terry Reedy wrote: > On 10/2/2017 12:44 AM, Guido van Rossum wrote: > > - There's no rationale for the *args, **kwds part of the breakpoint() >> signature. (I vaguely recall someone on the mailing list asking for it but >> it seemed far-fetched

Re: [Python-Dev] PEP 553

On 10/2/2017 12:44 AM, Guido van Rossum wrote: - There's no rationale for the *args, **kwds part of the breakpoint() signature. (I vaguely recall someone on the mailing list asking for it but it seemed far-fetched at best.) If IDLE's event-driven GUI debugger were rewritten to run in the

Re: [Python-Dev] PEP 553

Hope you don't mind me CC'ing python-dev. On Sun, Oct 1, 2017 at 9:38 AM, Barry Warsaw wrote: > You seem to be in PEP review mode :) > > What do you think about 553? Still want to wait, or do you think it’s > missing anything? So far, all the feedback has been positive, and

Re: [Python-Dev] PEP 553, v3

Barry Warsaw wrote: > Here’s an update to PEP 553, which makes $PYTHONBREAKPOINT a first class > feature. I’ve also updated PR #3355 with the implementation to match. I've been in contact with Elizaveta Shashkova from JetBrains. She gave a great talk at Pycon 2017 which influenced my thinking

Re: [Python-Dev] PEP 553, v3

On 9/13/2017 10:12 PM, Barry Warsaw wrote: Here’s an update to PEP 553, which makes $PYTHONBREAKPOINT a first class feature. I’ve also updated PR #3355 with the implementation to match. Looks pretty good to me. Reading the PR eliminated my remaining uncertainties. -- Terry Jan Reedy

[Python-Dev] PEP 553, v3

Here’s an update to PEP 553, which makes $PYTHONBREAKPOINT a first class feature. I’ve also updated PR #3355 with the implementation to match. Cheers, -Barry PEP: 553 Title: Built-in breakpoint() Author: Barry Warsaw Status: Draft Type: Standards Track Content-Type:

Re: [Python-Dev] PEP 553: Built-in debug()

On 9/7/2017 10:45 PM, Barry Warsaw wrote: On Sep 7, 2017, at 16:19, Terry Reedy wrote: I think breakpoint() should have a db= parameter so one can select a debugger in one removable line. The sys interface is more useful for IDEs to change the default, possible with other

[Python-Dev] PEP 553: Built-in debug()

Barry Warsaw writes: > and you would drop into the debugger after foo() but before bar(). > More rationale and details are provided in the PEP: > > https://www.python.org/dev/peps/pep-0553/ > > Unlike David, but like Larry, I have a prototype implementation: > >

Re: [Python-Dev] PEP 553 V2 - builtin breakpoint() (was Re: PEP 553: Built-in debug())

On 7 September 2017 at 20:02, Adrian Petrescu wrote: > Would that not be a security concern, if you can get Python to execute > arbitrary code just by setting an environment variable? Not really, as once someone has write access to your process environment, you've already

Re: [Python-Dev] PEP 553 V2 - builtin breakpoint() (was Re: PEP 553: Built-in debug())

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 It would appear to be more secure to define specific meanings for particular values of the environment variable.  S -BEGIN PGP SIGNATURE- Version: CryptUp 4.4.3 Gmail Encryption https://cryptup.org Comment: Seamlessly send, receive and

Re: [Python-Dev] PEP 553 V2 - builtin breakpoint() (was Re: PEP 553: Built-in debug())

Would that not be a security concern, if you can get Python to execute arbitrary code just by setting an environment variable? On Thu, Sep 7, 2017 at 10:47 PM, Barry Warsaw wrote: > On Sep 7, 2017, at 19:34, Nick Coghlan wrote: > > > Now that you put it

Re: [Python-Dev] PEP 553 V2 - builtin breakpoint() (was Re: PEP 553: Built-in debug())

On Sep 7, 2017, at 19:34, Nick Coghlan wrote: > Now that you put it that way, it occurs to me that CI environments > could set "PYTHONBREAKPOINTHOOK=sys:exit" to make breakpoint() an > immediate failure rather than halting the CI run waiting for input > that will never

Re: [Python-Dev] PEP 553: Built-in debug()

On Sep 7, 2017, at 18:03, Fernando Perez wrote: > Ah, perfect! I've subscribed to the PR on github and can pitch in there > further if my input is of any use. Awesome, thanks! -Barry signature.asc Description: Message signed with OpenPGP

Re: [Python-Dev] PEP 553: Built-in debug()

On Sep 7, 2017, at 16:19, Terry Reedy wrote: > I think breakpoint() should have a db= parameter so one can select a debugger > in one removable line. The sys interface is more useful for IDEs to change > the default, possible with other args (like breakpoints and colors)

Re: [Python-Dev] PEP 553 V2 - builtin breakpoint() (was Re: PEP 553: Built-in debug())

On 7 September 2017 at 19:17, Barry Warsaw wrote: > On Sep 7, 2017, at 18:12, Nick Coghlan wrote: >> >> Related to this is the suggestion that we make the default >> sys.breakpointhook() a no-op, so that accidentally checking in calls >> to breakpoint() won'

Re: [Python-Dev] PEP 553 V2 - builtin breakpoint() (was Re: PEP 553: Built-in debug())

On Sep 7, 2017, at 18:12, Nick Coghlan wrote: > > Related to this is the suggestion that we make the default > sys.breakpointhook() a no-op, so that accidentally checking in calls > to breakpoint() won' t hang CI systems. > > Then folks that wanted to use the functionality

Re: [Python-Dev] PEP 553 V2 - builtin breakpoint() (was Re: PEP 553: Built-in debug())

On 7 September 2017 at 11:43, Barry Warsaw wrote: > Environment variable > > > Should we add an environment variable so that ``sys.breakpointhook()`` > can be > set outside of the Python invocation? E.g.:: > > $ export

Re: [Python-Dev] PEP 553: Built-in debug()

On 2017-09-07 23:00:43 +, Barry Warsaw said: On Sep 7, 2017, at 14:25, Barry Warsaw wrote: I’ll see what it takes to add `header` to pdb.set_trace(), but I’ll do that as a separate PR (i.e. not as part of this PEP). Turns out to be pretty easy.

Re: [Python-Dev] PEP 553: Built-in debug()

On 9/7/2017 4:19 PM, Terry Reedy wrote: A somewhat separate point: the name breakpoint() is slightly misleading, which has consequences if it is (improperly) called more than once. While breakpoint() acts as a breakpoint, what it does (at least in the default pdb case) is *initialize* and

Re: [Python-Dev] PEP 553: Built-in debug()

On 9/7/2017 12:52 PM, Barry Warsaw wrote: On Sep 7, 2017, at 07:46, Guido van Rossum wrote: Without following all this (or the PEP, yet) super exactly, does this mean you are satisfied with what the PEP currently proposes or would you like changes? It's a little unclear

Re: [Python-Dev] PEP 553: Built-in debug()

On Sep 7, 2017, at 14:25, Barry Warsaw wrote: > > I’ll see what it takes to add `header` to pdb.set_trace(), but I’ll do that > as a separate PR (i.e. not as part of this PEP). Turns out to be pretty easy. https://bugs.python.org/issue31389

Re: [Python-Dev] PEP 553: Built-in debug()

On Sep 7, 2017, at 12:09, Fernando Perez wrote: >> The PEP has an open issue regarding breakpoint() taking *args and **kws, >> which would just be passed through the call stack. It sounds like you’d be >> in favor of that enhancement. > > If you go witht the `(*a, **k)`

Re: [Python-Dev] PEP 553: Built-in debug()

On Sep 7, 2017, at 13:52, Terry Reedy wrote: > pdb.set_trace is a public and stable interface. IDLE's is private and likely > to be initially unstable. I can imagine that the function that I would want > to bind to sys.__breakpoint__ would be a bound method To be

Re: [Python-Dev] PEP 553: Built-in debug()

On Sep 7, 2017, at 14:04, Fred Drake wrote: > > On Thu, Sep 7, 2017 at 4:52 PM, Terry Reedy wrote: >> Environmental variables tend to be a pain on Windows and nigh unusable by >> beginners. Leaving that aside, I see these problems with trying to use one >>

Re: [Python-Dev] PEP 553: Built-in debug()

On Thu, Sep 7, 2017 at 4:52 PM, Terry Reedy wrote: > Environmental variables tend to be a pain on Windows and nigh unusable by > beginners. Leaving that aside, I see these problems with trying to use one > for IDLE's *current* debugger. > > pdb is universal, in the sense of

Re: [Python-Dev] PEP 553: Built-in debug()

On 9/7/2017 12:50 PM, Barry Warsaw wrote: On Sep 6, 2017, at 23:10, Terry Reedy wrote: Environmental variables are set to strings, not objects. It is not clear how you intend to handle the conversion. The environment variable names a module import path. Without

Re: [Python-Dev] PEP 553: Built-in debug()

On 2017-09-07 00:20:17 +, Barry Warsaw said: Thanks Fernando, this is exactly the kind of feedback from other debuggers that I’m looking for. It certainly sounds like a handy feature; I’ve found myself wanting something like that from pdb from time to time. Glad it's useful, thanks for

[Python-Dev] PEP 553 V2 - builtin breakpoint() (was Re: PEP 553: Built-in debug())

Thanks for all the great feedback folks! Here then is PEP 553 version 2. The notable changes are: * Change the name of the built-in from debug() to breakpoint() * Modify the signature to be breakpoint(*args, **kws) https://www.python.org/dev/peps/pep-0553/ Included below for convenience.

Re: [Python-Dev] PEP 553: Built-in debug()

On Sep 7, 2017, at 10:00, Christian Heimes wrote: > Setuptools' entry points [1] use colon between import and function, e.g. > "pdb:set_trace" would import pdb and then execute set_trace. The > approach can be augmented to allow calling a class method, too. > > So > >

Re: [Python-Dev] PEP 553: Built-in debug()

On 2017-09-07 09:50, Barry Warsaw wrote: > On Sep 6, 2017, at 23:10, Terry Reedy wrote: >> >> Environmental variables are set to strings, not objects. It is not clear >> how you intend to handle the conversion. > > The environment variable names a module import path. Without

Re: [Python-Dev] PEP 553: Built-in debug()

On Sep 7, 2017, at 07:46, Guido van Rossum wrote: > Without following all this (or the PEP, yet) super exactly, does this mean > you are satisfied with what the PEP currently proposes or would you like > changes? It's a little unclear from what you wrote. I’m also unsure

Re: [Python-Dev] PEP 553: Built-in debug()

On Sep 6, 2017, at 23:10, Terry Reedy wrote: > > Environmental variables are set to strings, not objects. It is not clear how > you intend to handle the conversion. The environment variable names a module import path. Without quibbling about the details of the syntax

Re: [Python-Dev] PEP 553: Built-in debug()

On Wed, Sep 6, 2017 at 11:59 PM, Terry Reedy wrote: > On 9/6/2017 6:45 PM, Barry Warsaw wrote: > >> On Sep 6, 2017, at 14:59, Terry Reedy wrote: >> >>> >>> Currently, the debugger is started in response to a menu seletion in the >>> IDLE process while the

Re: [Python-Dev] PEP 553: Built-in debug()

On 9/6/2017 6:45 PM, Barry Warsaw wrote: On Sep 6, 2017, at 14:59, Terry Reedy wrote: Currently, the debugger is started in response to a menu seletion in the IDLE process while the python process is idle. One reason for the 'idle' requirement' is because when code is

Re: [Python-Dev] PEP 553: Built-in debug()

On 9/6/2017 6:24 PM, Barry Warsaw wrote: On Sep 6, 2017, at 10:14, Fabio Zadrozny 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,

Re: [Python-Dev] PEP 553: Built-in debug()

On Sep 6, 2017, at 16:55, Fernando Perez wrote: > > If I may suggest a small API tweak, I think it would be useful if > breakpoint() accepted an optional header argument. In IPython, the equivalent > for non-postmortem debugging is IPython.embed, which can be given a

Re: [Python-Dev] PEP 553: Built-in debug()

If I may suggest a small API tweak, I think it would be useful if breakpoint() accepted an optional header argument. In IPython, the equivalent for non-postmortem debugging is IPython.embed, which can be given a header. This is useful to provide the user with some information about perhaps

Re: [Python-Dev] PEP 553: Built-in debug()

On Sep 6, 2017, at 14:59, Terry Reedy wrote: > > Currently, the debugger is started in response to a menu seletion in the IDLE > process while the python process is idle. One reason for the 'idle' > requirement' is because when code is exec-uting, the loop that reads >

Re: [Python-Dev] PEP 553: Built-in debug()

On Sep 6, 2017, at 10:14, Fabio Zadrozny 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,

Re: [Python-Dev] PEP 553: Built-in debug()

On 9/6/2017 10:42 AM, Barry Warsaw wrote: I don’t think that’s a good idea. pdb is a thing, and that thing is the standard library debugger. I don’t think ‘pdb’ should be the term we use to describe a generic Python debugger interface. That to me is one of the advantages of PEP 553; it

Re: [Python-Dev] PEP 553: Built-in debug()

On Sep 6, 2017, at 10:19, Guido van Rossum wrote: > > 99% of the time I use a debugger I use pdb.set_trace(). The pm() stuff is > typically useful for debugging small, simple programs only -- complex > programs likely hide the exception somewhere (after logging it) so there's

Re: [Python-Dev] PEP 553: Built-in debug()

99% of the time I use a debugger I use pdb.set_trace(). The pm() stuff is typically useful for debugging small, simple programs only -- complex programs likely hide the exception somewhere (after logging it) so there's nothing for pdb.pm() to look at. I think Barry is wisely focusing on just the

Re: [Python-Dev] PEP 553: Built-in debug()

Hi Barry, I think it's a nice idea. 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(),

Re: [Python-Dev] PEP 553: Built-in debug()

On Wed, Sep 6, 2017 at 7:39 AM, Barry Warsaw wrote: >> On Tue, Sep 5, 2017 at 7:58 PM, Nathaniel Smith wrote: >> This would also avoid confusion with IPython's very >> useful debug magic: >> >>

Re: [Python-Dev] PEP 553: Built-in debug()

On Sep 6, 2017, at 07:46, Guido van Rossum wrote: > > IIRC they indeed insinuate debug() into the builtins. My suggestion is also > breakpoint(). breakpoint() it is then! I’ll rename the sys hooks too, but keep the naming scheme of the existing sys hooks. Cheers, -Barry

Re: [Python-Dev] PEP 553: Built-in debug()

On Wed, Sep 6, 2017 at 10:46 AM, Guido van Rossum wrote: > IIRC they indeed insinuate debug() into the builtins. My suggestion is > also breakpoint(). > I'm also a bigger fan of the `breakpoint` name. `debug` as a name is already pretty widely used, plus breakpoint is more

Re: [Python-Dev] PEP 553: Built-in debug()

IIRC they indeed insinuate debug() into the builtins. My suggestion is also breakpoint(). On Wed, Sep 6, 2017 at 7:39 AM, Barry Warsaw wrote: > On Sep 5, 2017, at 20:15, Guido van Rossum wrote: > > > > Yeah, I like the idea, but I don't like the debug() name

Re: [Python-Dev] PEP 553: Built-in debug()

On Sep 5, 2017, at 19:31, Giampaolo Rodola' wrote: > > True. Personally I have a shortcut in my IDE (Sublime) so I when I type "pdb" > -> TAB it auto completes it. > > Somehow I think debug() would make this a bit harder as it's more likely a > "debug()" line will pass

Re: [Python-Dev] PEP 553: Built-in debug()

On Sep 5, 2017, at 20:15, Guido van Rossum wrote: > > Yeah, I like the idea, but I don't like the debug() name -- IIRC there's a > helper named debug() in some codebase I know of that prints its arguments > under certain circumstances. > > On Tue, Sep 5, 2017 at 7:58 PM,

Re: [Python-Dev] PEP 553: Built-in debug()

Yeah, I like the idea, but I don't like the debug() name -- IIRC there's a helper named debug() in some codebase I know of that prints its arguments under certain circumstances. On Tue, Sep 5, 2017 at 7:58 PM, Nathaniel Smith wrote: > On Tue, Sep 5, 2017 at 6:14 PM, Barry Warsaw

Re: [Python-Dev] PEP 553: Built-in debug()

On Tue, Sep 5, 2017, at 19:57, Steven D'Aprano wrote: > Sorry, are we to interpret this as you asking that the PEP be rejected? > I can't tell whether you are being poetic and actually think the PEP is > a good idea, or whether you have written it to have it rejected and > prevent anyone else

Re: [Python-Dev] PEP 553: Built-in debug()

On Tue, Sep 05, 2017 at 06:14:12PM -0700, Barry Warsaw wrote: > I’ve written a PEP proposing the addition of a new built-in function > called debug(). Adding this to your code would invoke a debugger > through the hook function sys.debughook(). [...] > P.S. This came to me in a nightmare on

Re: [Python-Dev] PEP 553: Built-in debug()

On Tue, Sep 5, 2017 at 6:14 PM, Barry Warsaw wrote: > I’ve written a PEP proposing the addition of a new built-in function called > debug(). Adding this to your code would invoke a debugger through the hook > function sys.debughook(). The 'import pdb; pdb.set_trace()' dance

Re: [Python-Dev] PEP 553: Built-in debug()

> It's a lot to type (27 characters). True. Personally I have a shortcut in my IDE (Sublime) so I when I type "pdb" -> TAB it auto completes it. > Python linters (e.g. flake8 [1]) complain about this line because it contains two statements. Breaking the idiom up into two lines further

[Python-Dev] PEP 553: Built-in debug()

I’ve written a PEP proposing the addition of a new built-in function called debug(). Adding this to your code would invoke a debugger through the hook function sys.debughook(). Like the existing sys.displayhook() and sys.excepthook(), you can change sys.debughook() to point to the debugger of