itertools
itertools copied to clipboard
track_caller for zip_eq
This is expected to panic on length mismatch
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 94.26%. Comparing base (
6814180) to head (a4622ae). Report is 141 commits behind head on master.
Additional details and impacted files
@@ Coverage Diff @@
## master #1031 +/- ##
==========================================
- Coverage 94.38% 94.26% -0.13%
==========================================
Files 48 50 +2
Lines 6665 6193 -472
==========================================
- Hits 6291 5838 -453
+ Misses 374 355 -19
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
:rocket: New features to boost your workflow:
- :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
Hi there, thanks for this.
@jswrenn I'm torn on this one: That track_caller is nice, but it does afaik not reliably catch all notable places: Here, we would "fix" next, but all functions calling next would still be unsolved. Thus, I'm unsure if we should start adopting this feature in itertools, especially if there are many places where its use is debatable.
It's an improvement but not a perfect fix. #[track_caller] is always a matter of best effort and it's not terrible when it fails to pinpoint the source of a bug, but it's useful when it does.