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

2019-05-12 Thread Chun-Yu Tseng
Change by Chun-Yu Tseng : -- pull_requests: +13175 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue22135> ___ ___ Python-bugs-list mai

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

2019-04-23 Thread 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/issue22

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

2017-01-06 Thread Chun-Yu Tseng
Chun-Yu Tseng added the comment: Ping :) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22135> ___ ___ Python-bugs-list

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

2016-12-16 Thread 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

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

2016-12-15 Thread 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

[issue26072] pdb fails to access variables closed over

2016-11-22 Thread 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> ___ __

[issue26072] pdb fails to access variables closed over

2016-11-16 Thread 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 (

[issue26072] pdb fails to access variables closed over

2016-11-16 Thread 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 (

[issue26072] pdb fails to access variables closed over

2016-11-15 Thread 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/i

[issue26072] pdb fails to access variables closed over

2016-10-16 Thread 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

[issue26072] pdb fails to access variables closed over

2016-09-27 Thread 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