-
Notifications
You must be signed in to change notification settings - Fork 1
Refactor module/script handling to share an interface. #16
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
Conversation
self.module_details | ||
except ImportError: | ||
traceback.print_exc() | ||
sys.exit(1) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this what we currently do if import fails?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change is comparable to what ScriptTarget does when the file doesn't exist. To retain the current behavior, the body of this check would be pass
. By adding this check early, it allows the main
routine to detect if a module is invalid for running, allowing main to bail early for an unrunnable target.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change has the other advantage of not dropping into interactive mode when the indicated module is unrunnable, comparable to a non-existent file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, my point is this is not a refactor, it's new behaviour.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, good point. I could perform the refactor as a separate commit. Let me know if that's something you'd like to see.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Possibly, though I would be careful with it - pdb invokes code in several different way (from command line, from the pdb prompt, from Pdb subclasses that various debuggers implement). I'd need to spend more time before I'm convinced that moving error detection around is safe (and the tests don't tell the whole story).
pdb has not been very well maintained in recent years. Xavier de Gaye and Daniel Hahler used to work on it and left some abandoned PRs. I tried to reach out to them to continue the work but they are not responding anymore. I think some their PRs should be updated and merged, they both knew what they were doing.
I've also been trying to go through the backlog of known bugs, and got some fixed, but it's always a problem to find someone to review. For instance this one is quite simple and it's open: python#26656
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good to know that pdb is in need of some love. If you wish to loop me in, I'll see what I can do to help. I don't have any spare bandwidth, but I expect to be able to review them eventually. I took a look at the one you mentioned and found it's already been addressed. Thanks for all your help.
Superseded by python#26992. |
This change explores the idea I suggested in python#26937, performing the module runability check early. For your consideration.