You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Increase test coverage of the random module #84227
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:
assignee=Noneclosed_at=<Date2020-03-23.15:42:53.971>created_at=<Date2020-03-23.09:01:11.482>labels= ['3.7', '3.8', '3.9', 'type-feature', 'tests', 'docs']
title='Increase test coverage of the random module'updated_at=<Date2020-03-30.20:39:49.887>user='https://github.com/serhiy-storchaka'
I'm against this doc change. While factually true, it is irrelevant and distracting to most users. We do not need to test and document every implementation detail, nor should we.
Yes, of course. The PR adds new tests for different types of arguments which currently are accepted (so it would be a regression if they will no accepted in new releases or in alternate implementations) and for types which currently are not accepted for reasons, so unexpected accepting may signal about using inefficient or incorrect algorithm.
For example, choice() works not only with lists, but with other sequences, so the implementation which works only with lists (for example the C implementation which uses the concrete C API) will fail with new tests. If we fix this hypothetical implementation by converting the argument to list (which would be inefficient for large collections), other new tests (which check that sets and iterators are not accepted) will fail.
Activity
serhiy-storchaka commentedon Mar 23, 2020
The propose test adds several tests for random module. Mainly tests for integer, sequence and iterable arguments.
It also documents that randrange() accepts non-integers.
rhettinger commentedon Mar 23, 2020
I'm against this doc change. While factually true, it is irrelevant and distracting to most users. We do not need to test and document every implementation detail, nor should we.
serhiy-storchaka commentedon Mar 23, 2020
What is wrong with adding more tests?
willingc commentedon Mar 30, 2020
Hi Raymond and Serhiy,
Serhiy, Was there a specific use case or regression that you felt the tests would be helpful?
serhiy-storchaka commentedon Mar 30, 2020
Yes, of course. The PR adds new tests for different types of arguments which currently are accepted (so it would be a regression if they will no accepted in new releases or in alternate implementations) and for types which currently are not accepted for reasons, so unexpected accepting may signal about using inefficient or incorrect algorithm.
For example, choice() works not only with lists, but with other sequences, so the implementation which works only with lists (for example the C implementation which uses the concrete C API) will fail with new tests. If we fix this hypothetical implementation by converting the argument to list (which would be inefficient for large collections), other new tests (which check that sets and iterators are not accepted) will fail.
willingc commentedon Mar 30, 2020
Thanks Serhiy for the explanation.
I agree with Raymond about the doc change.
Raymond, These tests, after reading Serihy's response, make sense to me. Let's revisit and reconsider the PR on the tests without the doc change.
Thanks!