[Python-Dev] PEP 553
Guido van Rossum
guido at python.org
Mon Oct 2 00:44:57 EDT 2017
Hope you don't mind me CC'ing python-dev.
On Sun, Oct 1, 2017 at 9:38 AM, Barry Warsaw <barry at python.org> 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 I think
> we can basically just close the open issues and both the PEP and
> implementation are ready to go.
> Happy to do more work on it if you feel it’s necessary.
I'm basically in agreement. Some quick notes:
- There's a comma instead of a period at the end of the 4th bullet in the
Rationale: "Breaking the idiom up into two lines further complicates the
use of the debugger," . Also I don't understand how this complicates use
(even though I also always type it as one line). And the lint warning is
actually useful when you accidentally leave this in code you send to CI
(assuming that runs a linter, as it should). TBH the biggest argument (to
me) is that I simply don't know *how* I would enter some IDE's debugger
programmatically. I think it should also be pointed out that even if an IDE
has a way to specify conditional breakpoints, the UI may be such that it's
easier to just add the check to the code -- and then the breakpoint()
option is much more attractive than having to look up how it's done in your
particular IDE (especially since this is not all that common).
- 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.)
- The explanation of the relationship between sys.breakpoint() and
sys.__breakpointhook__ was unclear to me -- I had to go to the docs for
understand that sys.__breakpointhook__ is simply initialized to the same
function as sys.breakpointhook, and the idea is that if you screw up you
can restore sys.breakpointhook from the other rather than having to restart
your process. Is that in fact it? The text "``sys.__breakpointhook__`` then
stashes the default value of ``sys.breakpointhook()`` to make it easy to
reset" seems to imply some action that would happen... when? how?
- Some pseudo-code would be nice. It seems that it's like this:
# in builtins
def breakpoint(*args, **kwds):
return sys.breakpointhook(*args, **kwds)
# in sys
def breakpointhook(*args, **kwds):
hook = os.getenv('PYTHONBREAKPOINT')
if hook == '0':
if not hook:
return pdb.set_trace(*args, **kwds)
if '.' not in hook:
mod = builtins
funcname = hook
modname, funcname = hook.rsplit('.', 1)
mod = sys.modules[modname]
func = getattr(mod, funcname)
return func(*args, **kwds)
__breakpointhook__ = breakpointhook
Except that the error handling should be a bit better. (In particular the
PEP specifies a try/except around most of the code in sys.breakpointhook()
that issues a RuntimeWarning and returns None.)
- Not sure what the PEP's language around evaluation of PYTHONBREAKPOINT
means for the above pseudo code. I *think* the PEP author's opinion is that
the above pseudo-code is fine. Since programs can mutate their own
environment, I think something like `os.environ['PYTHONBREAKPOINT'] =
'foo.bar.baz'; breakpoint()` should result in foo.bar.baz() being imported
and called, right?
- I'm not quite sure what sort of fast-tracking for PYTHONBREAKPOINT=0 you
had in mind beyond putting it first in the code above.
- Did you get confirmation from other debuggers? E.g. does it work for
IDLE, Wing IDE, PyCharm, and VS 2015?
- I'm not sure what the point would be of making a call to breakpoint() a
special opcode (it seems a lot of work for something of this nature). ISTM
that if some IDE modifies bytecode it can do whatever it well please
without a PEP.
- I don't see the point of calling `pdb.pm()` at breakpoint time. But it
could be done using the PEP with `import pdb; sys.breakpointhook = pdb.pm`
right? So this hardly deserves an open issue.
- I haven't read the actual implementation in the PR. A PEP should not
depend on the actual proposed implementation for disambiguation of its
specification (hence my proposal to add pseudo-code to the PEP).
That's what I have!
--Guido van Rossum (python.org/~guido <http://python.org/%7Eguido>)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev