lint: resolve B905

[matsumotosan]

What does this PR do?

Resolve B905: zip-without-explicit-strict

Before submitting

• Was this discussed/agreed via a Github issue? (no need for typos and docs improvements)
• Did you read the contributor guideline, Pull Request section?
• Did you make sure to update the docs?
• Did you write any new necessary tests?

PR review

Anyone in the community is free to review the PR once the tests have passed.
If we didn't discuss your PR in Github issues there's a high chance it will not be merged.

Did you have fun?

Make sure you had fun coding 🙃

---

📚 Documentation preview 📚: https://torchmetrics--2154.org.readthedocs.build/en/2154/

[SkafteNicki]

Sadly this is not supported before python 3.10, so we really cannot add this in the next foreseeable future.

[Borda]

Sadly this is not supported before python 3.10, so we really cannot add this in the next foreseeable future.

@matsumotosan Sorry for that. I made it as todo, did not know it was not feasible 😿

UPDATE: we can still have it would even be cool, such that we will add it as extra kwarg or define it as our own private func:

def _zip(*args, **kwargs) -> ...:
	kw_strict = {"strict": True} if <python 3.10+> and "strict" not in kwargs else {}
	return zip(*args, **kwargs, **kw_strict)

[Borda]

@matsumotosan made some adjustments; could you pls check...

[codecov]

Codecov Report

Merging #2154 (940f4e6) into master (beae928) will increase coverage by 0%.
Report is 1 commits behind head on master.
The diff coverage is 94%.

Additional details and impacted files

@@          Coverage Diff           @@
##           master   #2154   +/-   ##
======================================
  Coverage      87%     87%           
======================================
  Files         293     294    +1     
  Lines       16417   16457   +40     
======================================
+ Hits        14273   14310   +37     
- Misses       2144    2147    +3     

[matsumotosan]

So there's a case where the length of items in the arguments to zip aren't equal in the call to _precision_at_recall in functional.classification.precision_fixed_recall (len(thresholds) is 4, but len(precision) and len(recall) are 5).

I haven't had the time to familiarize myself with this function so wanted to see if anyone had any immediate ideas before I go deeper into the code.

[Borda]

So there's a case where the length of items in the arguments to zip aren't equal in the call to _precision_at_recall in functional.classification.precision_fixed_recall (len(thresholds) is 4, but len(precision) and len(recall) are 5).

this is good finding, @SkafteNicki

[SkafteNicki]

So there's a case where the length of items in the arguments to zip aren't equal in the call to _precision_at_recall in functional.classification.precision_fixed_recall (len(thresholds) is 4, but len(precision) and len(recall) are 5).

I haven't had the time to familiarize myself with this function so wanted to see if anyone had any immediate ideas before I go deeper into the code.

It is correct that in most cases thresholds is one value shorter than the corresponding values. That is mostly to be consistent with how scikit learn is doing it. In those cases I guess the argument would need to be False