Issue 15273: Remove unnecessarily random behavior from test_unparse.py (original) (raw)

Issue15273

Created on 2012-07-07 12:29 by larry, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
submitted_patch_Issue15273 Daniel.Cioata,2013-01-28 08:06 patch file for removing the random functionality from Tools/parser/test_unparse.py review
Messages (9)
msg164831 - (view) Author: Larry Hastings (larry) * (Python committer) Date: 2012-07-07 12:29
Tools/parser/test_unparse.py is the regression test suite for Tools/unparse. To save time, if the "cpu" resource is not enabled it only test unparsing ten files. However it picks these files at random. It would be nice if the test was 100% repeatable. It might be nice if it picked the most tortuous ten files. What ten are the most tortuous is not immediately clear, but a nice first approximation might be to pick the largest ten, provided the stat calls don't themselves make the test slow again.
msg164832 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2012-07-07 12:31
Ideally, it would pick a small number of files that are likely to fully exercise Python's grammar. So things like Lib/test/test_grammar might be useful to include. Or perhaps there should be a Python file somewhere in Lib/test whose entire purpose is to contain at least one example of each grammar construction?
msg165026 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2012-07-08 17:15
I thought we had other tests that did this as well (pickle?). If you need reproducibility you check the random seed and reuse it.
msg165063 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2012-07-09 05:11
test_grammar should be that file, though, people often forget to update it.
msg180838 - (view) Author: Daniel Cioata (Daniel.Cioata) Date: 2013-01-28 08:06
a solution for this issue
msg357726 - (view) Author: Batuhan Taskaya (BTaskaya) * (Python committer) Date: 2019-12-02 18:24
@pablogsal should we add Lib/test/test_grammar by default to every test? Also if this is still needed @Daniel.Cioata do you still want to prepare another patch for current version?
msg357729 - (view) Author: Pablo Galindo Salgado (pablogsal) * (Python committer) Date: 2019-12-02 21:45
> @pablogsal should we add Lib/test/test_grammar by default to every test? Also if this is still needed @Daniel.Cioata do you still want to prepare another patch for current version? I think is a good idea, let me check how complete is the current version first.
msg359205 - (view) Author: Batuhan Taskaya (BTaskaya) * (Python committer) Date: 2020-01-02 17:25
I guess this resolved with PR 17738
msg359208 - (view) Author: Pablo Galindo Salgado (pablogsal) * (Python committer) Date: 2020-01-02 18:22
> I guess this resolved with PR 17738 Yup. Closing as per PR 17738.
History
Date User Action Args
2022-04-11 14:57:32 admin set github: 59478
2020-01-02 18:22:22 pablogsal set status: open -> closedresolution: fixedmessages: + stage: patch review -> resolved
2020-01-02 17:25:19 BTaskaya set messages: +
2019-12-02 21:45:15 pablogsal set messages: +
2019-12-02 18:24:31 BTaskaya set nosy: + pablogsal, BTaskayamessages: +
2014-10-05 18:52:18 berker.peksag set nosy: + berker.peksagstage: needs patch -> patch reviewcomponents: + Testsversions: + Python 3.5
2013-01-28 08:06:12 Daniel.Cioata set files: + submitted_patch_Issue15273nosy: + Daniel.Cioatamessages: +
2012-07-09 05:11:33 benjamin.peterson set nosy: + benjamin.petersonmessages: +
2012-07-08 17:15:43 r.david.murray set nosy: + r.david.murraymessages: +
2012-07-07 12:31:50 mark.dickinson set messages: +
2012-07-07 12:30:15 mark.dickinson set keywords: + easyassignee: mark.dickinson -> versions: + Python 3.4, - Python 3.3
2012-07-07 12:29:12 larry create