Bug fixes

B1) Execute script in its own namespace

(script was executed in pdb.py name space. E.g one
could do 
print line_prefix 
in your script and one would get pdb's line_prefix variable
(and I guess if was  possible to accidentally stomp on
pdb internals from the script))

B2)  Remove pdb.py's path from sys.path.

(pdb.py path was not removed from sys.path.. While
normally this is not a  problem, it CAN cause hard to
diagnose problems.  e.g. if your script needs to
override some of std modules and you put them in some
location and set PYTHONPATH accordingly, then
everything works without
pdb, but when you run under pdb (which is normally
located with the rest of python std libs) your
overriding suddenly breaks)

This addresses CVS Bug report #751124, part 2

B3)  Fix handling of breakpoints "file_name:line_no"

(pdb was failing to set the breakpoint specified as 
"b file_name:100"
when file_name did not end with ".py", and was not an
absolute path.This is quite bad as many scripts
commonly do not have ".py" suffix...
In at least some cases, (e.g when running under emacs
gud)  user can't workaround this problem, as the
"break" command is issued by another program..)



Enhancements:

E1) Now pdb gets directly to the 1st line of script 

(the CVS version of pdb required doing "step" twice
before you get to the first line of your code: both
ugly and annoying)

E2) Restart the program (and preserve debugger state,
such as breakpoints) if program being debugged exits 

(CVS version was exitting on program's exitNow debugger
does not die on script's exit, taking all the settings
with it)

E3) Enter post-mortem debugging if the program throws an
uncaught exception

(CVS version was simply dying in this case
This addresses CVS bug report #751124, part 1)

All changes apply to the command line interface of pdb.py
Ie. only when pdb.py invoked as
"pdb.py script"

The only exception is B3 which fixes a bug in do_break()

Logged In: YES 
user_id=971153

I am attaching a new version of the patch.

Changes include:
    1) the new patch is against the latest pdb.py v 1.67
    2) it allows to debug code protected by
if __name__== '__main__' conditional (the first version of
the patch did not set __name__, so this code was not
reachable)....


Also, is there anything I can do to help with consideration
of this patch? 

Logged In: YES 
user_id=971153

Another iteration of the patch
1. Allow to set bkpts while in post-mortem  debuggin (which
now  happens in the same instance of pdb)

2. Against latest pdb.py (1.69)

Logged In: YES 
user_id=469548

I just looked at the bug-fixing parts for now. B1 and B2 are
clear-cut and I'll check in the fix once I've fully
processed the patch.

B3: Could you give an example of a script where this bug
appears (copy/paste console session would be nice)? I'm not
sure I get the bug.

Logged In: YES 
user_id=971153

Yes, here is an example of B3 type of bug

The program:

bagira:~/python/dist/src/Lib> cat pdb_t
x=1
y=2
x=3

and the bug:
bagira:~/python/dist/src/Lib> ../python pdb.py pdb_t

> <string>(1)?()
(Pdb) b pdb_t:2   <-- fails
***  'pdb_t' not found from sys.path  
(Pdb) s
--Call--
> /home/ilya/python/dist/src/Lib/pdb_t(1)?()
-> x=1
(Pdb) b pdb_t:2  <---again fails
***  'pdb_t' not found from sys.path 
(Pdb) b 2             <--but succeeds w/o file name
Breakpoint 1 at /home/ilya/python/dist/src/Lib/pdb_t:2 

Logged In: YES 
user_id=469548

Ah, I've got it now. However, your fix (which should be in
lookupmodule, like you suggested) is a bit too broad. 'b
pbd_t:2' works, but 'b
<random_other_file_in_script_directory>:2' also works, while
it shouldn't. Maybe we should use _initial_file here as well?

Logged In: YES 
user_id=469548

On the enhancements:

E1. Should be fine (this is the frame.f_lineno <= 0 part of
the patch, right?).

E2. Nice addition. It could do with better docs. Come to
think of it, all of this needs to be documented. A new doc
section on running the module as a script would be nice. I
can write it, but it would be great if you could 

E3. Yes!

In general: 

* I'm not completely sure about this, but I'm thinking
do_debug_script() would fit better as a method on the Pdb
class. It seems to have a bit of feature envy towards the
pdb class.  What do you think?

* I'd like to rename the method to runscript() for
consistency with the rest of pdb.

* You might want to read
http://python.org/peps/pep-0008.html, especially the
sections on Whitespace and Comments. While you're at it,
http://python.org/peps/pep-0257.html is important too.

That's it... for now.

Logged In: YES 
user_id=971153

> (this is the frame.f_lineno <= 0 part of the patch, right?).

Yes

>However, your fix   (which should be in lookupmodule), is a bit
> too broad. 'b pbd_t:2' works, but 
>'b <random_other_file_in_script_directory>:2' also works, while
>it shouldn't. 

I am not sure I agree here: e.g even in CVS version of pdb
you can set a breakpoint in a random file (as long as this
file is specified via absolute path or can be found in
sys.path)...
E.g. 
'b pydoc.py:124' succeeds even if your script never loads pydoc
And I think this is in general a useful behaviour as
debugger has no way (in general) to know that a particular
source file may be loaded in the future..

As far as placement of it in lookupmodule(). Well, I guess I
was afraid to change existing function (as it could
theoretically break some other code). Another issue is that,
strictly speaking, lookupmodule() already does more then
just looks up modules, so I did not want to add even more to
it...I don't feel strongly either way, so if you think
lookupmodule() is the place to fix B3, let me know...

>do_debug_script() would fit better as a method on the Pdb
>class. It seems to have a bit of feature envy towards the
>pdb class.  What do you think?

Well, yes and no: e.g basic setup for the script debugging 

        g={"__name__" : "__main__"} 
        l=g  
        pdb._initial_file=pdb.canonic(filename)
        statement='execfile( "'+ filename+'")'
        pdb.run(statement, globals=g, locals=l)

could indeed become a method of Pdb, but I am not  sure
about the wrapping loop/postmortem, which would result in a
method which never return...

> I'd like to rename the method to runscript() for
>consistency with the rest of pdb.

I could add runscript() with the above code in it and still
have the main() function which is responsible for the loop
and postmortem.. Would it be better?

>E2. Nice addition. It could do with better docs. 
> Come to think of it, all of this needs to be documented. A
new 
>doc section on running the module as a script would be nice.

Could you elaborate a bit on what would like to see in such
a doc? (E.g normaly such docs would include command line
options, but we don't have any and the cli itself is already
documented)

.

Logged In: YES 
user_id=469548

"As far as placement of it in lookupmodule(). Well, I guess
I was afraid to change  existing function (as it could
theoretically break some other code)."

Yes, I still think it should be in lookupmodule. I was also
a bit worried about backwards compatibility, but that's part
of the reason why I wanted to disallow 'b
<random_other_file_in_script_directory>:2'. If we don't
disallow it, it'll become impossible to break (for example)
in the profile.py module on sys.path if you have a file
called 'profile' in the current directory. That would suck.

"I could add runscript() with the above code in it and still
have the main() function which is responsible for the loop
and postmortem.. Would it be better?"

Yes, let's see how that looks.

"Could you elaborate a bit on what would like to see in such
a doc?"

Well, the (to me) at first surprising behavior of restarting
when the script ends and the fact that it enters post-mortem
debugging on an uncaught exception. Exactly the things this
patch adds.

Logged In: YES 
user_id=971153

I am attaching a new version, changes include

1) B3 fix moved into lookupmodule(), note that the original
 B3 description above was slightly wrong: pdb failed to set
bkpts even when absolute path for a main script was
specified, the old patch worked, but it was more of an
accident,now this case is handled explicitly

2) Code rearrangements, reformatting, etc

3) Special handling of SystemExit. Previous version of patch
handled SystemExit like any other exception with stack
trace, postmortem, etc. Now SystemExit just result in a
message and program restart...

Would it be a good idea to move the rest of the __main__
code into main()?

Still no doc fixes...

Please let me know if you see any problems with this code.

Logged In: YES 
user_id=469548

"Would it be a good idea to move the rest of the __main__
code into main()?"

Yes, that would be good.

Samll nits:

* Please add a self._initial_file = '' to Pdb.__init__ so we
can get rid of the getattr calls and just use attribute lookup.
* Why are you using mainpyfile if you could use
_initial_file? I was sort of hoping we could get rid of
mainmodule and mainpyfile some day.

Logged In: YES 
user_id=971153

I am attaching the new version of the patch

The patch:

- moves all of the __main__ code into main()
- gets rid off mainmodule and filename global variables
- global mainpyfile is replaced with an attribute of Pdb
- _initial_file pdb attribute was changed into
_wait_for_mainpyfile attribute to better reflect the purpose
(which is to flag whether the main script has been reached)

Obviously killing of globals is an API change, but  that API
has never been documented and is not part of __all__

Logged In: YES 
user_id=469548

I checked this in now (as rev 1.70 of pdb.py), because I
didn't want to drop this after beta1, which is due on
thursday. I would still like to see a doc patch, but it
doesn't have to be in before beta1. Sooner rather than later
though.

Thanks for the patch and going through the various
iterations with me!