[issue36537] except statement block incorrectly assumes end of scope(?).

Saim Raza added the comment: > Knowing that pdb stops just before the interpreter executes the line after > pdb.set_trace(), what prevents you from writing the pdb.set_trace() statement > before the last line of the except clause ? Of course, that can be done. The issue here is to get the

[issue36537] except statement block incorrectly assumes end of scope(?).

Xavier de Gaye added the comment: > Now, I need to *inconveniently* put some dummy code after the ser_trace call > every time I want to access the exception inside the except block Knowing that pdb stops just before the interpreter executes the line after pdb.set_trace(), what prevents you

[issue36537] except statement block incorrectly assumes end of scope(?).

SilentGhost added the comment: I cannot imagine that the fix would be straightforward or that there is much use of this particular pattern. Perhaps, a note in the docs suggesting post_mortem() for except clauses over set_trace() would be more appropriate. --

[issue36537] except statement block incorrectly assumes end of scope(?).

Saim Raza added the comment: Thanks, SilentGhost! However, should we try to fix set_trace as well to avoid hassles to other users? -- ___ Python tracker ___

[issue36537] except statement block incorrectly assumes end of scope(?).

SilentGhost added the comment: Saim, a .post_mortem could be used instead. As I noted, it works just fine. -- ___ Python tracker ___

[issue36537] except statement block incorrectly assumes end of scope(?).

Saim Raza added the comment: This is pretty unintuitive from a user's stand point. Now, I need to *inconveniently* put some dummy code after the ser_trace call every time I want to access the exception inside the except block. Also, this is a change in behavior from Python 2.7. Is this

[issue36537] except statement block incorrectly assumes end of scope(?).

Xavier de Gaye added the comment: The *** Tracing *** section [1] of Objects/lnotab_notes.txt in the cpython repository provides detailed explanations for when the line trace function is called. [1]

[issue36537] except statement block incorrectly assumes end of scope(?).

Xavier de Gaye added the comment: @Saim wrote > https://docs.python.org/3/reference/compound_stmts.html#the-try-statement says This is correct, the disassembly of foo.py below demonstrates that point: BEGIN_FINALLY at bytecode index 36 starts the implementation of the 'finally' clause that

[issue36537] except statement block incorrectly assumes end of scope(?).

Saim Raza added the comment: https://docs.python.org/3/reference/compound_stmts.html#the-try-statement says = except E as N: foo = is converted to the following statement: = except E as N: try: foo finally: del N =

[issue36537] except statement block incorrectly assumes end of scope(?).

Xavier de Gaye added the comment: This is not a bug. On the first pdb session from the OP: True --Return-- > (5)()->None -> import pdb; pdb.set_trace() (Pdb) print("err" in locals()) False <-- BUG?? Pdb has stopped on a '--Return--' line event, so we are already outside

[issue36537] except statement block incorrectly assumes end of scope(?).

Change by Karthikeyan Singaravelan : -- nosy: +xdegaye ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36537] except statement block incorrectly assumes end of scope(?).

SilentGhost added the comment: Can confirm also on 3.6, but this seems to be something particular to set_trace, when pdb is entered via post_mortem, the variable is available in locals(). -- nosy: +SilentGhost, barry ___ Python tracker

[issue36537] except statement block incorrectly assumes end of scope(?).

New submission from Saim Raza : If pdb.set_trace() is the last statement in the first code snippet, variable 'err' is (wrongly?) excluded from locals(). Adding any code after the pdb.set_trace() statement makes 'err' available in locals. In [2]: try: ...: raise ValueError("I am