* Fixes 'RelatedManager' object is not iterable in ListSerializer.to_representation.(#8726)
* Change to only BaseManager
* Commit unit test
* Update tests/test_serializer_lists.py
* Update tests/test_serializer_lists.py
* Update tests/test_serializer_lists.py
* Update tests/test_serializer_lists.py
* Update tests/test_serializer_lists.py
* Update tests/test_serializer_lists.py
* Format import
* Format import
Co-authored-by: Asif Saif Uddin <auvipy@gmail.com>
* FloatField will crash if the input is a number that is too big
* Added Unit test for float field overflow error catch
* Removed random import
* Removed additional imported ValidationError
* Update rest_framework/fields.py
* Update tests/test_fields.py
Co-authored-by: Asif Saif Uddin <auvipy@gmail.com>
* Added normalize parameter to DecimalField to be able to strip trailing zeros. Fixes#6151.
* Updated docs to include normalize option on DecimalField
* Fixed linting error in test_fields
* Removed comment and renamed normalize to normalize_output as suggested in code review
Co-authored-by: Tom Christie <tom@tomchristie.com>
Importing anything `rest_framework` causes `django.test` to be imported.
This is because DRF registers a receiver on the
`django.test_signals.setting_changed` signal.
This is not really a problem, but it is good to avoid this because it
bloats the memory with unnecessary modules (e.g. `django.test`,
`django.core.servers.basehttp`, `socketserver`) and increases the
startup time. It also doesn't feel right to import test code into
non-test code.
Try to import the signal from a core module if possible.
Note that there's another `django.test` import in `MultiPartRenderer`,
however this import is done lazily only if the functionality is used so
can be easily avoided.
- Replace the broken Bootswatch-Link with an Jsdelivr-Link as suggested at https://bootswatch.com/help/
- Updated the stated Bootstrap version
- Added a note that the Bootstrap version must match the default one
Co-authored-by: Tom Christie <tom@tomchristie.com>
We depend on pytz, but until late last year we got it implicitly through
depending on Django. Since their release 4.0, however, they no longer
depend on pytz; commit 250479dc3 added the dependency directly to our
metadata in setup.py, but the documentation about dependencies (most
importantly, the instructions for new contributors) was left untouched.
This commit updates the new contributor instructions to suggest an
"editable installation" of the project at the step that previously had
users manually install Django. In this mode, pip fetches and installs
the project dependencies automatically (so in the unlikely event we grow
another dependency, that doc doesn't need to be changed again) and makes
the project available to the virtualenv's python as a normal package,
but doesn't require reinstallation for mundane edits.
`PendingDeprecationWarning` means "we plan to deprecate, but haven't
yet." A feature that's to be deleted in the next release is not planned
to be deprecated; it **is** deprecated.
> Base class for warnings about features which are obsolete and expected
> to be deprecated in the future, but are not deprecated at the moment.
>
> This class is rarely used as emitting a warning about a possible
> upcoming deprecation is unusual, and DeprecationWarning is preferred for
> already active deprecations.
https://docs.python.org/3/library/exceptions.html#PendingDeprecationWarning
Co-authored-by: Tom Christie <tom@tomchristie.com>
When DRF 3.14 is released, these exception classes will be meaningless,
so we can delete them (this has always been done).
A previous PR removed the last incidence of `RemovedInDRF313Warning`,
but didn't outright delete the class for fear of shipping a breaking
change: https://github.com/encode/django-rest-framework/pull/8589
