| msg257378 - (view) |
Author: Lasse Schuirmann (Lasse Schuirmann) * |
Date: 2016-01-02 22:30 |
| You can see this when importing the Flask `request` object in a file that is doctested. The `request` object will throw a RuntimeError when one tries to access any attribute. Doctest tries to `inspect.unwrap` all objects in the file in order to find out if they're doctestable functions - and apparently only catches the `AttributeError` exception. Thus it crashes :) |
|
|
| msg257379 - (view) |
Author: Lasse Schuirmann (Lasse Schuirmann) * |
Date: 2016-01-02 22:35 |
| (Closed) issue at the flask repository of this: https://github.com/mitsuhiko/flask/issues/1680 Also IIRC this worked back with Python 3.4 but do not consider this a fact yet. (At least the tests ran on Fedora...) |
|
|
| msg257387 - (view) |
Author: Steven D'Aprano (steven.daprano) *  |
Date: 2016-01-02 23:43 |
| doctest doesn't crash -- it is a regular exception, not a crash. "Crash" means "Hard crashes of the Python interpreter – possibly with a core dump or a Windows error box." In other words, a segmentation fault or other low-level crash, not an exception. I'm not convinced that this is a problem with doctest, it looks to me like a broken-by-design flaw in requests. If you try to access an attribute that doesn't exist, you should get AttributeError, not RuntimeError. I don't understand the justification given on the requests tracker for why the attribute access fails, but I would expect that any exception other than AttributeError, or a subclass of such, is a clear bug in requests. I don't think it is doctest's responsibility to have special handling for an ill-designed proxy class, but I'll hold off closing the ticket for a few days in case anyone makes a good argument for why this is a doctest bug. |
|
|
| msg257467 - (view) |
Author: Lasse Schuirmann (Lasse Schuirmann) * |
Date: 2016-01-04 16:51 |
| Sorry for giving it the wrong category. I personally think both projects should solve this. IMO it would be nice if doctest is robust against modules that for some reason (be they ill designed or not; I guess if you search a lot you find a project that needs to raise a custom exception when accessing `__wrapped__`). At the same time I do think the Flask request object could handle this better but lack the ability to explain that to them with substantial reasoning. The problem is that both of you don't want to solve this problem at their side, @steven.daprano, would you mind speaking with the Flask people directly? I'm not affiliated to them. |
|
|
| msg257478 - (view) |
Author: R. David Murray (r.david.murray) * |
Date: 2016-01-04 18:36 |
| No, I don't think doctest should be made robust against RuntimeErrors. doctest's purpose is to check for bugs, and IMO this is a bug in flask. In particular, it is not doctest that flask is not cooperating with, it is hasattr. It used to be that hasattr would mask errors raised, and this caused a number of both debugging and production problems, to the point where hasattr was not considered safe to use. But it eventually got fixed: http://www.gossamer-threads.com/lists/python/dev/856859 |
|
|
| msg257479 - (view) |
Author: R. David Murray (r.david.murray) * |
Date: 2016-01-04 18:42 |
| Gah. Having hit send I of course had second thoughts. doctest is suppose to *report* bugs, so there *is* a doctest bug here: it should be capturing that and probably other errors and reporting them, instead of just producing a traceback, I think. |
|
|
| msg347791 - (view) |
Author: Mickaël Schoentgen (Tiger-222) * |
Date: 2019-07-13 09:46 |
| Working on it at EuroPython 2019. FTR I tested on Python 3.6.9, 3.7.4 and 3.9.0a0 without issue. I think this was fixed with https://github.com/rtweeks/werkzeug/commit/c643980b93e9bde4431cd99ece30f07e00160f84. But the doctest issue remains and this is on what I will focus. |
|
|
| msg347845 - (view) |
Author: Mickaël Schoentgen (Tiger-222) * |
Date: 2019-07-13 16:45 |
| Attached a simple reproduction script. |
|
|