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 args (like breakpo
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:
>
> https://github.c
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
___
Python
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) bound to
> the callab
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.
https://bugs.python.org/issue31389
https
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 start
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 from what you wrote.
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
https://github.com/python/cpython/pull/3438
Cheers,
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)` pass-through API, would
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 pedantic, you’re not suppos
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
>> for IDLE's *current* debugger.
>>
>>
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 working with any pytho
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 quibbling about
the detail
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
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
>
> "package.module:myclass.c
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 quibbling about
>
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 whether Terry is good
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 (because honestly, I’m n
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 python process is idle. One reason for
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 exec-uting, the loop t
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, which I
think is a bet
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 header.
> This is useful t
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 wher
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
> commands, executes them
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, it'd be debug_break fo
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 sep
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
> nothing for pdb
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 ab
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(), and
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:
>>
>> https://ipython.readthedocs.io/en/stable/interactive/magics.html#magic-debug
>> and which might al
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
signature.asc
Desc
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 specific in naming
wha
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 -- IIRC there's
> a helper named deb
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 unnoticed.
> For this re
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, Nathaniel Smith 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, Nathaniel Smith wrote:
> On Tue, Sep 5, 2017 at 6:14 PM, Barry Warsaw wrote:
> > I’ve
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
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 Su
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 is *extremely* obsc
> 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
complicates
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
41 matches
Mail list logo
