-
-
Notifications
You must be signed in to change notification settings - Fork 30.9k
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
doctest should allow custom sys.displayhook #70280
Comments
The purpose of doctest's - verify interactive examples. But if After https://bugs.python.org/issue8048, sys.displayhook can't be PS: In fact, right now this issue can be workarrounded if you instead |
What problem does replacing __displayhook__ provoke? What solution do you propose instead of 8048, which fixed a bug? |
I don't know for sure. But the documentation says "These objects contain the original values of displayhook and excepthook at the start of the program." So, other code in stdlib may assume something about __displayhook__ value. I.e. it writes the values it gets to sys.stdout. (Apparently, doctest thinks so.) Such assumptions should be documented, before people can override __displayhook__ safely.
IMHO, it's not a bug. Why not override sys.displayhook just for doctests in this application? PS: |
Noam Yorav-Raphael, I tried to add you because this is pushing back against your patch in bpo-8408. It's been some years now, and nobody has cared enough to pursue it, so I'll just close this if you still don't care ;-) As doctest's original author, I appreciate why 8408 was done, but don't think it was "a good" solution. In fact doctest can have no idea whether an example was _intended_ to be run with or without a custom shell's displayhook function invoked to massage the output first. So more sensible would have been to add a new doctest directive + optional argument, to make the intent explicit. Which is certainly more work, and hasn't actually come up as "a problem" yet. |
Oops! Should be bpo-8048. |
Tim, thanks for letting me know. I certainly don't mind if you close this bug, since it undoes my old (and still relevant) fix. |
Tim, lets decide on this simple issue. To me, https://bugs.python.org/issue8048 was obviously a bad thing. While it "fixes" one application, which customize sys.displayhook in a strange way - it break testing almost everyone, which do sys.displayhook customization. See e.g. https://github.com/sympy/sympy/blob/master/conftest.py or https://github.com/diofant/diofant/blob/master/conftest.py. BTW, SymPy is far more popular library than dreampie, which is py2-only and looks unmaintained. Last, but not least - introduced doctest's behaviour wasn't documented. It break things in a surprising way and do this silently... There is a documentation issue if you decide to keep this "feature". Noam, what do you think about fixing your problem with mock.patch? >>> import sys
>>> from unittest.mock import patch
>>> with patch('sys.displayhook', sys.__displayhook__):
... doctest.testmod() Tentative patch attached. |
Hi, I think that using mock.patch to fix the problem is fine. I personally Thanks! On Mon, Apr 26, 2021 at 10:08 AM Sergey B Kirpichev <report@bugs.python.org>
|
Noam, that's because Python has your patch :-) But if we revert one - mentioned solution with mock.patch will work. Please, tell us if you find it bad for any reason. |
Yes, sorry, I didn't remember the history exactly. I don't have a strong opinion. I'm okay with reverting the behavior to use sys.displayhook. Thanks, |
To summarize:
|
I think that the fix in 25fbb89 was correct. Doctest runs the code in slightly different environment than the pure Python. Doctest patches several other global attributes: @skirpichev, would explicit setting
Note that simply reverting 25fbb89 will break not only original OP's code, but will likely break doctests which set |
@serhiy-storchaka, probably yes. See the current workaround, same uses e.g. the SymPy. But putting this stuff to every doctest will be too verbose... That's why I think that the doctest module should honor the sys.displayhook value.
Probably, so. But any good reason why the doctest can't honor the sys.displayhook value?
I doubt. See this. |
What are your thoughts about adding a new doctest directive or optional argument, as @tim-one suggested, to make the transition more smooth? It should be noted that while unittest wrappers around doctest (DocTestCase, DocFileTest, DocFileSuite) support arguments setUp and tearDown for setting up the test environment and cleaning it up, the native doctest interface (testmod, testfile) does not support such feature. How are you going to set up |
@serhiy-storchaka, unless I miss something, the suggestion was to implement the current workaround (for #52296) as an option (not a default). That's definitely a more work without clear benefits: we can restore old behaviour (as after #52296), using setUp() method.
You are right, I use the pytest's doctest plugin, which uses lower-level doctest's interfaces. Perhaps, testmod/testfile should expose setUp/tearDown stuff. But I'm not sure that this should be handled by this issue. |
This reverts patch from https://bugs.python.org/issue8048 Now it's possible to test interactive examples for applications, which use cusomized sys.displayhook, e.g. SymPy, without nasty workarrounds (i.e. overriding the sys.__displayhook__ value before tests).
This partially reverts patch from https://bugs.python.org/issue8048 Now it's possible to test interactive examples in applications, which use cusomized sys.displayhook, e.g. SymPy, without nasty workarrounds (i.e. overriding the sys.__displayhook__ value before each tests).
Slightly different version: #111871 (sys.displayhook value will be restored at the end of doctest). |
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:
Linked PRs
The text was updated successfully, but these errors were encountered: