Smoren
feat: random integer iterators and streams
Pull Request Test Coverage Report for Build 13788547605
Warning: This coverage report may be inaccurate.
This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.
- For more information on this, see Tracking coverage changes with pull request builds.
- To avoid this issue with future PRs, see these Recommended CI Configurations.
- For a quick fix, rebase this PR at GitHub. Your next report should be accurate.
Details
- 24 of 24 (100.0%) changed or added relevant lines in 4 files are covered.
- No unchanged relevant lines lost coverage.
- Overall coverage remained the same at 100.0%
| Totals | |
|---|---|
| Change from base Build 13062161073: | 0.0% |
| Covered Lines: | 1482 |
| Relevant Lines: | 1482 |
💛 - Coveralls
Hi @studiosi! Thank you for PR! I see that you used a third-party library to implement new functionality. The thing is, I would like itertools to remain a dependency-free library, so I would like to ask you to rework this PR so that new features do not use a third-party library.
I would also like to ask you to implement tests using data providers, similar to the tests written earlier.
Thanks!
I don't understand the rationale of including a statistical self-coded random number generator in this library. It is a complex change that would introduce a lot of possible bugs and maintenance costs. If the choice is math.Random this library would be useless for most serious purposes, can you clarify what's the expected outcome?
Hi @studiosi!
Have you ever encountered issues in a project due to transitive dependencies? For example, when a library requires one version of another library as a dependency, but your project needs a different version of it?
This is quite a common problem, so I want to keep itertools-ts free from any dependencies.
Also, I'd like to add that itertools-ts is a general-purpose library, and using the standard Math.random() will be perfectly fine for it. Those who need more powerful tools for working with random numbers can use the random library directly.
Yes, I know why not having dependencies is desirable. I also think that implementing a statistically sound random number generator should not be something that this library should do.
@studiosi I think that using Math.random() is a better decision than adding transitional dependencies.