Zachary Ware added the comment:
Terry J. Reedy added the comment:
> The problem is that this permissiveness does not apply to subsidiary files
> discovered from and run by a main file, even though it should. The current
> workaround is to explicitly set use_resources for the benefit of subsidiary
> files, as in test_idle.py.
This is exactly what inspired this issue, though with
test_codecmaps_*.py rather than test_idle.
> As I see it, the main point of this patch, somewhat obscured by the title, is
> to extend the current resource permissiveness from tests *in* main files run
> as main to tests in other files discovered and run from a main file. It also
> extends the permisiveness to any test not run by regrtest (ie, by unittest).
I did choose the title rather poorly, but yes, this is the real point.
> The key change is
> - if sys._getframe(1).f_globals.get("__name__") == "__main__":
> + if not regrtest_run:
>
> 'regrtest_run == True' is currently spelled 'use_resources is not None', so
> the latter could be used instead to replace the frame-check without otherwise
> adding new code.
I think using the 'regrtest_run' flag is more explicit about why we're
just letting anything go, and could potentially be useful in other
situations as well (though I'm coming up blank on what any of those
might be right now).
<snip>
> Serhiy is concerned about the possible booby-trap for users that run slow
> resource intensive tests. Some thoughts:
<snip thoughts>
I agree with your thoughts here, which if I'm not mistaken basically
boil down to "Yes, it's a booby-trap, but it's not a lethal one and we
can document around most of it."
> *If -u is added to unittest (and 'use=' to .main), a default of all would be
> the right thing for subfile targets, even if not for file and multi-file
> targets.
I'm not sure I understand this line. But I do have an initial patch
adding -u to unittest which I will be posting shortly which, if
accepted, should render this issue moot.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue18492>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
