* Install and configure flake8-bugbear to spot mutable default arguments
* Fix mutable default arguments in OrderingFilter methods
- Fixed get_default_valid_fields() and get_valid_fields() methods in filters.py
- Changed context={} default parameter to context=None to prevent mutable default anti-pattern
- Added proper None checking with context = {} assignment inside methods
Why this fix is important:
- Mutable default arguments (context={}) create shared state across function calls
- Same dict object gets reused, potentially causing unexpected side effects
- This is a well-known Python anti-pattern that can lead to bugs
What was changed:
- Line 249: get_default_valid_fields(self, queryset, view, context=None)
- Line 285: get_valid_fields(self, queryset, view, context=None)
- Added 'if context is None: context = {}' in both methods
Testing results:
- All existing filter tests pass (pytest tests/test_filters.py)
- Custom verification script confirms fix works correctly
- Maintains backward compatibility
- No breaking changes to API
Addresses GitHub issue #9741
---------
Co-authored-by: Bruno Alla <alla.brunoo@gmail.com>
* Do not ignore .codespellrc from git
* Add rudimentary codespell config
* Add pre-commit definition for codespell
* more custom skips for codespell - long lines, lines with ú etc
* [DATALAD RUNCMD] Do interactive fixing of some ambigous typos
=== Do not change lines below ===
{
"chain": [],
"cmd": "codespell -w -i 3 -C 2 ./docs/community/release-notes.md",
"exit": 0,
"extra_inputs": [],
"inputs": [],
"outputs": [],
"pwd": "."
}
^^^ Do not change lines above ^^^
* BF: pre-commit needs to duplicate some of the skips for codespell
Known issue -- yet to be addressed:
https://github.com/codespell-project/codespell/issues/3196
* Move codespell configuration into setup.cfg
* Change semantic of OR of two permission classes
The original semantic of OR is defined as: the request pass either of the two has_permission() check, and pass either of the two has_object_permission() check, which could lead to situations that a request passes has_permission() but fails on has_object_permission() of Permission Class A, fails has_permission() but passes has_object_permission() of Permission Class B, passes the OR permission check. This should not be the desired permission check semantic in applications, because such a request should fail on either Permission Class (on Django object permission) alone, but passes the OR or the two.
My code fix this by changing the semantic so that the request has to pass either class's has_permission() and has_object_permission() to get the Django object permission of the OR check.
* Update rest_framework/permissions.py
* Update setup.cfg
Co-authored-by: Mark Yu <markyu98@outlook.com>
Co-authored-by: Tom Christie <tom@tomchristie.com>
* Use `--strict-markers` instead of `--strict`, as per this warning:
```
/.../_pytest/config/__init__.py:1183: PytestDeprecationWarning: The --strict option is deprecated, use --strict-markers instead.
```
* Remove config option 'testspath' - pytest is logging a warning about this being unknown:
```
/.../_pytest/config/__init__.py:1233: PytestConfigWarning: Unknown config option: testspath
```
I can't find any reference to it in the pytest docs or changelog.
Thanks to Jon Dufresne (@jdufresne) for review.
Co-authored-by: Asif Saif Uddin <auvipy@gmail.com>
Co-authored-by: Rizwan Mansuri <Rizwan@webbyfox.com>
- tox: move {posargs} to the end, so that it can override previous
entries, e.g. `-ra` when `-rw` was used.
- pytest: add `-ra` to addopts: it is good to see a summary of skipped
and failed tests at the end.
It is useful to see if tests itself are covered after all - missing
coverage there typically indicates dead/missed code paths.
This also uses `source=.` and includes (with run and report), to help
Codecov with reporting.
Ref: https://github.com/encode/django-rest-framework/pull/5956