* Python code cleanup by the cleanup-python-code Jenkins job.
This pull request was generated by the cleanup-python-code Jenkins job, which ran
```
cd lms/djangoapps/dashboard; find . -type f -name '*.py' | while read fname; do sed -i 's/ # lint-amnesty, pylint: disable=super-with-arguments//; s/ # lint-amnesty, pylint: disable=import-error, wrong-import-order//; s/ # lint-amnesty, pylint: disable=wrong-import-order//' "$fname"; done; find . -type f -name '*.py' | while read fname; do pyupgrade --exit-zero-even-if-changed --py3-plus --py36-plus --py38-plus "$fname"; done; isort --recursive .
```
The following packages were installed:
`pyupgrade,isort`
* feedback done
Co-authored-by: Zulqarnain <muhammad.zulqarnain@arbisoft.com>
While deleting a post, the number of comments are retrieved where API reports wrong number of total pages due to PY3 incompatible division:
response.data["pagination"]
{'previous': None, 'count': 3, 'num_pages': 1.02, 'next': 'http://apros.devstack.lms?ajax=1&page=2'}
Which results in PageNotFoundError:
is_thread)):
File "/edx/src/discussion-edx-platform-extensions/social_engagement/engagement.py", line 382, in _get_paginated_results
has_next = response.data["pagination"]["next"]
File "/edx/app/edxapp/edx-platform/lms/djangoapps/discussion/rest_api/views.py", line 526, in retrieve
form.cleaned_data["requested_fields"],
File "/edx/app/edxapp/edx-platform/lms/djangoapps/discussion/rest_api/api.py", line 1074, in get_response_comments
raise PageNotFoundError("Page not found (No results on this page).")
openedx.core.lib.exceptions.PageNotFoundError: Page not found (No results on this page).
Technically, both "2020-10-20T23:59:00Z" and "2020-10-20T23:59:00+00:00"
are ISO-8601 compliant, though the latter is preferred. The Discussions
API uses the "Z" notation for almost all its dates, except for the
course blackout dates (those times when students aren't allowed to post
anything because it would threaten exam integrity). That's because the
blackout dates are manually formatted using datetime.isoformat().
As best as I can tell, we've always passed back the "+00:00" for the
blackout dates. But at some point, this broke the expectations of the
mobile apps, which expect the "+Z" format, like the rest of the API.
This commit changes the blackout dates to be returned in +Z format when
the blackout datetimes are specified by the user in UTC (which is almost
always the case–I suspect the mobile clients would break if the dates
were specified in other timezones anyhow).
These were originally fixed individually, but had to be reverted, and
are now combined in one commit. The originals were:
7b9040f6b0 This enum was backwards
8774ff1f9b Use ref_name to disambiguate serializers that drf-yasg would otherwise assume are the same.
8a44397139 Is this field missing because it is None?
4a1154a7ca Give a safer buffer for clearing the rate limiting
64c47856dd DRF 3.7.4 changed how you delegate to another view, so don't
7359ca4fb2 Is this right? It fixes two tests
fdd66e5390 Adjust the expected error message for DRF 3.7.7
9257f68fd8 The default TIME_ZONE should be UTC
