New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pdb: fix for 1326406 (import __main__ pdb failure) #42886
Comments
The patch allows pdb to debug program which |
Logged In: YES I think that exposing pdb's namespaces for debugged code is y.py: Pdb.__dict__['do_break'] = destroy # pdb's break = destroy with your patch:
$ python2.5 -m pdb x.py
> /home/xyz/python/x.py(1)<module>()
-> import y
(Pdb) Pdb.__dict__['do_break']
<function do_break at 0xb7cafdf4>
(Pdb) break
(Pdb) n
> /home/xyz/python/x.py(2)<module>()
-> exec(y.puff)
(Pdb) n
> /home/xyz/python/x.py(3)<module>()
-> print "X"
(Pdb) Pdb.__dict__['do_break']
<function destroy at 0xb7cb81b4>
(Pdb) break
Iam crashing your HOME and deleting your FILES I think that this patch can't be accepted due to above |
Logged In: YES I do see your point (In fact it was me who submitted the I do want to bring a couple of points:
google search for "from __main__ import" results in about 1M
So, basically, it boils down to this: what's worse breaking As a middle ground it might be a good idea to expand the What do you think? |
Logged In: NO
|
Logged In: YES Sorry I forget to login in;)The comment below is from me. |
Logged In: YES
Do you mean examples of intentional interference with Anyway, here are some examples of unintentional interference:
--------------------------------------------------- --------------------------------------------------- When a program does run in pdb's namespace (as would be the There could be a better way... |
Logged In: YES I'm attaching an alternative patch: the program stil runs in import pdb
pdb.main() So the main program cann't accidentally stomp on pdb (there is still a bit of namespace pollution in the main |
Logged In: YES Another iteration of the patch Now __main__ namespace is explicitly initialized before the As a side effect, __file__ will now be set correctly in the |
Thanks for the patch, committed as rev. 54363. |
I am not sure whether it is appropriate to comment on a closed issue, I have recently stumbled on this bug running python 2.5. While tracking Thus both pdb and runpy pop sys.argv[0], but (after this patch) pdb Furthemore, runpy injects __loader__ in the "main" namespace while pdb While I cannot point out any specific problems (other than inability to Finally a nit: why does _runscript use run("execfile(filename)") instead |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: