Release: https://pypi.org/pypi/flake8-builtins/2.0.0
Homepage: https://github.com/gforcada/flake8-builtins
Diff: https://github.com/gforcada/flake8-builtins/compare/1.5.3...2.0.0
Stubsabot analysis of the diff between the two releases:
- 0 public Python files have been added.
- 0 files included in typeshed's stubs have been deleted.
- 1 file included in typeshed's stubs has been modified or renamed: `flake8_builtins.py`.
- Total lines of Python code added: 338.
- Total lines of Python code deleted: 546.
If stubtest fails for this PR:
- Leave this PR open (as a reminder, and to prevent stubsabot from opening another PR)
- Fix stubtest failures in another PR, then close this PR
Note that you will need to close and re-open the PR in order to trigger CI
Co-authored-by: stubsabot <>
Release: https://pypi.org/pypi/braintree/4.17.0
Homepage: https://developer.paypal.com/braintree/docs/reference/overview
If stubtest fails for this PR:
- Leave this PR open (as a reminder, and to prevent stubsabot from opening another PR)
- Fix stubtest failures in another PR, then close this PR
Note that you will need to close and re-open the PR in order to trigger CI
Co-authored-by: stubsabot <>
Release: https://pypi.org/pypi/pytz/2022.4
Homepage: http://pythonhosted.org/pytz
If stubtest fails for this PR:
- Leave this PR open (as a reminder, and to prevent stubsabot from opening another PR)
- Fix stubtest failures in another PR, then close this PR
Note that you will need to close and re-open the PR in order to trigger CI
Co-authored-by: stubsabot <>
I think stubsabot has been a really big success. Let's change it to a daily workflow, so that we don't get an avalanche of PRs every Friday, and so that we can see more quickly if a PR changing stubsabot has accidentally broken the script. (If that _does_ happen, it should be pretty easy to just revert the commit that accidentally broke stubsabot, and go back to a version that works pretty well.)
Fixes#8778
Note that not fixing this has some advantages, particularly if stubsabot
waits a little while after releases before making PRs (as discussed
earlier). Specifically, it gives us more coverage of upstream versions
and might provide a natural division of changes, compared to PRs that
make updates corresponding to several upstream versions.
The final mypy_primer report for #8762 was an empty diff. Considering the number of issues we've had with our requests stubs over the last year, it feels like it makes sense to add a test case to make sure that it doesn't regress.
