On Tue, Jan 21, 2020 at 6:24 AM David Carson <[email protected]> wrote: > > Aaron Meurer wrote: > > I'm not sure what would cause this. Is the set_trace() in some code > > that does any sort of metaprogramming? > > No metaprogramming. Simple 300 line script. > > > It might also be related to some sort of permissions issue with the > > source file. > > Note that the source is readable by pudb, since it shows source correctly as > long as I enter the debugger from the command-line invocation first (-m > pudb). So, it does not seem like this could be the issue.
At a technical level, PuDB reads the source from the linecache module. Python's import mechanism should put the source into the linecache module whenever a file is first executed, so PuDB can't find the source, it means that somehow that part failed. Normally this only happens for automatically generated code (anything ran through exec() or compile() won't be put in the linecache unless you do so manually), or a C extension. To see what is going on, you would need to see if your file is in linecache.cache. > > > Another thought: if you are using Windows or macOS and the filename > > has uppercase characters, the case insensitive filesystem could be > > confusing the linecache. I've seen issues with this myself. I > > recommend avoiding uppercase characters in Python source filenames. > > The file did have mixed case, so this provided a tiny bit of hope. However, > the code is on a Linux server and I'm debugging on that server. > Nevertheless, I tried copying the script to a lowercase-only name because > what can it hurt? It did not fix the problem. Grasping at strings, but are there odd filesystems involved here? Aaron Meurer > > One more piece of information: I use tmux. However, like I said originally, > I have been using pudb for a long time and I've never had any problem with > pudb's interaction with tmux. > > On Mon, Jan 20, 2020 at 6:20 PM Aaron Meurer <[email protected]> wrote: >> >> I'm not sure what would cause this. Is the set_trace() in some code >> that does any sort of metaprogramming? >> >> It might also be related to some sort of permissions issue with the >> source file. >> >> Another thought: if you are using Windows or macOS and the filename >> has uppercase characters, the case insensitive filesystem could be >> confusing the linecache. I've seen issues with this myself. I >> recommend avoiding uppercase characters in Python source filenames. >> >> Aaron Meurer >> >> On Mon, Jan 20, 2020 at 4:07 PM David Carson <[email protected]> wrote: >> > >> > Andreas, >> > >> > This is the first Python 3 script of any substance I have debugged using >> > pudb. >> > >> > I just wrote a trivial script in Python 3 and it did not display this >> > behavior. Running without the '-m pudb' on the command line worked >> > correctly--breakpoint encountered, source code displayed. >> > >> > On Mon, Jan 20, 2020 at 5:53 PM Andreas Kloeckner >> > <[email protected]> wrote: >> >> >> >> David Carson <[email protected]> writes: >> >> > I am trying to debug a Python 3 script. When I add a 'set_trace()' call >> >> > and then run the script normally, the breakpoint is hit but there is no >> >> > source code displayed. I am running the script in the directory where >> >> > the >> >> > script is located. >> >> >> >> Interesting. I've never seen this happen. Does this occur for any Py3 >> >> script you attempt to debug? >> >> >> >> Andreas >> > >> > _______________________________________________ >> > Pudb mailing list -- [email protected] >> > To unsubscribe send an email to [email protected] _______________________________________________ Pudb mailing list -- [email protected] To unsubscribe send an email to [email protected]
