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
Tests for pdb import ~/.pdbrc #62601
Comments
After a clean check out and a successful build of Python 3.4, doctests were failing when running test_pdb. Specifically, doctests were failing because they were getting a "*** NameError: name 'execfile' is not defined" when running. It turns out that my ~/.pdbrc file contained a call to execfile(). While removing this line from my ~/.pdbrc file remedied the issue for me, test_pdb probably shouldn't be reading from global configuration when testing the pdb module. |
I have been thinking about a fix for this. A straightforward fix would be to add a kwarg readrc=True to the constructor of Pdb that will default to reading the rc files as it does now, and allows disabling this default. The implication is that all tests in stdlib will need to use pdb.Pdb(readrc=False).set_trace() instead of just pdb.set_trace(). This would impact (from what I can see) doctest.py, test_pdb.py and test_doctest.py, and would also require some kind of warning/notice instructing test writers to follow this convention. I started working on a patch for this (attached), which works for test_pdb, but I can't get the tests in test_doctest to work yet. It would also be useful to have a test that demonstrates this problem and I'm not sure what the best approach is... should it show that doctests fail? If so, and knowing that Pdb reads rc files from a) $HOME/.pdbrc and b) ./.pdbrc, the test could: Then to trigger the problem it could write a small script containing a doctest that internally does pdb.set_trace(), run the module and demonstrate that the doctest failed. And then teardown all the temporary resources in a finally block. |
Adding a parameter is an enhancement. Probably not a bad thing to have anyway, but it can only go in 3.5. Since this isn't something that causes problems for production code, that seems fine. (The alternative would be to say have a private class variable that the tests would set/reset, but that is pretty ugly). The final patch will need doc changes and a whatsnew entry. |
Picked up Martin's patch and added docs, misc/NEWS entry, and a test for readrc=False behavior. |
Thanks, Sam. It is more helpful if the NEWS entry is *not* put in the patch given the current state of the tooling. What's needs to be added is an entry in Doc/whatsnew/3.5. For the new test, you can take advantage of the temp_dir and EnvironmentVarGuard helpers in test.support to simplify the code and make it more bullet proof. |
New changeset ee0bbfd972de by Łukasz Langa in branch 'default': |
Thanks for your contribution, Martin and Sam! |
New changeset 09c730db1aac by Victor Stinner in branch 'default': |
New changeset 5aa77974dd56 by Victor Stinner in branch 'default': |
(Copied from my post to python-checkins.) |
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: