[issue22135] allow to break into pdb with Ctrl-C for all the commands that resume execution

[Chun-Yu Tseng]

Change by Chun-Yu Tseng :


--
pull_requests: +13175
stage:  -> patch review

___
Python tracker 
<https://bugs.python.org/issue22135>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22135] allow to break into pdb with Ctrl-C for all the commands that resume execution

[Chun-Yu Tseng]

Chun-Yu Tseng  added the comment:

My bad, I totally forget this patch. Need to spend some time to retest my code 
and catch up with current development flow. Thanks for reminding.

--

___
Python tracker 
<https://bugs.python.org/issue22135>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22135] allow to break into pdb with Ctrl-C for all the commands that resume execution

[Chun-Yu Tseng]

Chun-Yu Tseng added the comment:

Ping :)

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue22135>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22135] allow to break into pdb with Ctrl-C for all the commands that resume execution

[Chun-Yu Tseng]

Chun-Yu Tseng added the comment:

Appreciate for your quick response. I have already left the reply in Rietveld.

I have uploaded a new patch with revised tests. In fact, the tests I wrote in 
the first patch are based on the style of `test_pdb2.py` in #7245 . But I am 
sure that now the new tests are better than the old because they run faster and 
source code looks simpler. (Note that these tests are still skipped to run on 
Windows)

Please tell me what can I do next :)

--
Added file: http://bugs.python.org/file45928/fix-cc-and-add-tests-v2.patch

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue22135>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22135] allow to break into pdb with Ctrl-C for all the commands that resume execution

[Chun-Yu Tseng]

Chun-Yu Tseng added the comment:

Here comes the patch:

1. Let Pdb can also resume from `return`, `until` and `next` commands when 
receiving Control-C.

2. Explicitly raise `bdb.BdbQuit` when an unexpected exception occurs in 
`sigint_handler`. See #24283.

3. Add two tests `test_break_during_interactive_input`, 
`test_resume_from_sigint` and some helper functions to `test_pdb.py` to make 
sure that Pdb behaves as we expected.
See below, Pdb resumes back in a wrong position when receiving Control-C.  The 
environment is Python 3.5.2 (Mac).  But Pdb works right in latest 
3.5/3.6/default now. So we should have tests here.
(Pdb) list
  1  import time
  2  def f():
  3  import pdb; pdb.Pdb().set_trace();
  4  ->delay()
  5  print("* f() done *")
  6
  7  def delay():
  8  time.sleep(3)
  (Pdb) c
^C
Program interrupted. (Use 'cont' to resume).
--Call--
> /usr/local/var/pyenv/versions/3.5.2/lib/python3.5/signal.py(45)signal()
-> @_wraps(_signal.signal)
(Pdb)



What this patch does NOT do are:

1. Let Pdb can resume from `step` command.
I tried by the same way like what I did for `continue/return/until/next` 
commands, but Pdb resumed back at the beginning of `sigint_handler`. The user 
should type in `continue` to go to the right place. I can't find an elegant way 
to work around it:
-> time.sleep(3)
(Pdb) s
^C--Call--
> /Users/chun-yutseng/Projects/cpython/Lib/pdb.py(189)sigint_handler()
-> def sigint_handler(self, signum, frame):
(Pdb) l
184  self.commands_defining = False # True while in the process of 
defining
185 # a command list
186  self.commands_bnum = None # The breakpoint number for which we 
are
187# defining a list
188
189  ->def sigint_handler(self, signum, frame):
190  if self.allow_kbdint:
191  raise KeyboardInterrupt
192  try:
193  self.message("\nProgram interrupted.")
194
(Pdb)

2. Let the two added tests can be run on Windows.
I tried, but when I found that I may need to use Windows-specific signals 
(CTRL_C_EVENT/CTRL_BREAK_EVENT) in `pdb.py` to let automated tests pass, I 
decided not to introduce such complexity.
So I use `@unittest.skipIf` to skip these two tests and tested the patch on 
Windows manually.


Call for review/advice/guides, please.

------
keywords: +patch
nosy: +Chun-Yu Tseng
versions: +Python 3.7 -Python 3.5
Added file: http://bugs.python.org/file45913/fix-cc-and-add-tests.patch

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue22135>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26072] pdb fails to access variables closed over

[Chun-Yu Tseng]

Chun-Yu Tseng added the comment:

Hey xdegaye, have you confirmed it?

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26072>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26072] pdb fails to access variables closed over

[Chun-Yu Tseng]

Chun-Yu Tseng added the comment:

Your solution is quite neat. 
But it still misses use cases of the `global` statement:

  1  y = 2
  2
  3  def f():
  4  y = 9
  5  -> import pdb; pdb.set_trace();
  6
  7  f()
(Pdb) global y; y
9
(Pdb) global y; y += 1; y
10
(Pdb) globals()['y']
2

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26072>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26072] pdb fails to access variables closed over

[Chun-Yu Tseng]

Chun-Yu Tseng added the comment:

The last patch in #21161 fixes some problems but also brings up critical issues:

(Pdb) list .
  1  y = 2
  2
  3  def f():
  4  y = 9
  5  z = 10
  6  -> import pdb; pdb.set_trace();
  7  f()
[EOF]
(Pdb) globals()['y']
9
(Pdb) global y; print(y)
9
(Pdb) globals()['z']
10

I think that we should not copy local variables to globals()  while doing 
execution. It will always bring out the wrong result of `globals()`.

So, the patch I proposed here is focused on "Showing Friendly Error Message" to 
let the users be less confused. 


# The patch works when a user tries to bound a free variable to a list 
comprehension. It will show the proper error message, too.

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26072>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26072] pdb fails to access variables closed over

[Chun-Yu Tseng]

Chun-Yu Tseng added the comment:

Call for review again.

Maybe xdegaye would like to take a look?
I found this related issue: #21161

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26072>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26072] pdb fails to access variables closed over

[Chun-Yu Tseng]

Chun-Yu Tseng added the comment:

Surrender.

After digging into the implementation of how CPython handles closures, I am 
sure that it is impossible to solve this problem now correctly. What I can do 
is create a patch to let Pdb print enough information when the problem occurs. 
It would look like:

(Pdb) ll
  3  def f():
  4  x = 1
  5  ->import pdb; pdb.set_trace()
(Pdb) (lambda: x)()

Pdb can not use the local variable 'x' to create a closure in
your evaluation. Instead, it tries to use 'x' in globals().
This behavior is due to the limitation of dynamic
interpretation within a debugger session.

Hint: type 'help interact' to check 'interact' command.

*** NameError: name 'x' is not defined

I believe it would be helpful and less annoyed for those who encounters this 
problem. Call for maintainers review, please.


PS.
1. Ruby does not have this problem. Whether it exists depends on how a 
programming language to implement closures. However, I think that what CPython 
do (by `PyCellObject`) is smart and efficient.

2. I tried to solve the problem by copying local variables to globals() (just 
like what `interact` command do), but it results in **more** problems. The most 
typical one is that if I eval `globals()` in such an affected environment, I 
will always get the wrong result.

3. I also tried to patch and evaluate again what user inputs when catching a 
closure-related `NameError`. Obviously, it is not a good idea due to side 
effects of evaluation.

4. The last possible solution I think of is import `ast` and do some hacking 
... it's overkill, and it also brings up other side effects.

--
keywords: +patch
Added file: http://bugs.python.org/file45115/default.patch

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26072>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26072] pdb fails to access variables closed over

[Chun-Yu Tseng]

Chun-Yu Tseng added the comment:

What Antony Lee mentioned are two different cases. 

The former is what PDB should behave because it is not reasonable to inspect a 
variable does not exist in the current frame. If you want to do so, you have to 
reference the variable `x` as a closure inside inner function `g` in your 
source code before running PDB.

The latter is same as what Jesús Gómez confirmed. It's a problem about creating 
correct closures in an interaction prompt of PDB. It can be found in almost 
every versions of Python. The following are several forms of the problem:


# (1) raise exception 

  1  def f():
  2  x = 2
  3  ->import pdb; pdb.set_trace();
(Pdb) (lambda: x)()
*** NameError: name 'x' is not defined


# (2) no exception, but get the wrong value

  1  x = 100
  2  def f():
  3  x = 2
  4  ->import pdb; pdb.set_trace();
  5  f()
(Pdb) x
2
(Pdb) (lambda: x)()
100


# (3) similar to (1), but this one usually makes me upset if I forget the cause 
of the problem

(Pdb) ll
  1  def f():
  2  ->import pdb; pdb.set_trace();
(Pdb) x = 5
(Pdb) [i for i in range(10) if (i % x) == 0]
*** NameError: name 'x' is not defined
(Pdb) x
5


It's easy to alleviate the problem by using `interact` command to start an 
interactive interpreter.

  1  def f():
  2  ->import pdb; pdb.set_trace();
(Pdb) x = 5
(Pdb) interact
*interactive*
>>> [i for i in range(10) if (i % x) == 0]
[0, 5]

Now the behavior looks right.

However, the problem still exists for those PDB users don't know how to pass 
it, and it's quite inconvenient to start an interactive interpreter every time. 
Maybe it's worth to keep the behavior of PDB consistent and expectable just 
like the behavior inside interactive interpreter.

I will try to send a patch to solve the problem in these days. Please stop me 
if it's inappropriate.

------
nosy: +Chun-Yu Tseng
versions: +Python 2.7, Python 3.3, Python 3.4, Python 3.7

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26072>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com