Przejrzałam wszystkie pliki pod kątem innych importów zlokalizowanych niezgodnie regułami przy użyciu poleceń grep -r -A 10000 '^.*class ' | grep '.*import ', grep -r -A 10000 '^.*def ' | grep '.*import ', grep 'import ' $(grep -rL 'class') oraz grep 'import ' $(grep -rL 'def ') (uznając słowa kluczowe class i def za pewną granicę między importami z początku pliku a jego resztą) i nie wykazały one żadnych anomalii poza tymi wymienionymi w issue #1620. W plikach tych przeniosłam wszystkie importy na początek tychże plików, ponieważ nie znalazłam żadnego uzasadnienia, żeby musiały tam pozostać.
Dodatkowo, w pliku schedule/models/event.py zmieniłam zapytania Term.objects.filter(event=self) na self.term_set.all() w celu wyeliminowania importu Term w tym module.
Natomiast w aplikacji enrollment przeniosłam ChangedDay oraz Freeday do osobnego pliku specialdays.py, żeby uniknąć problemów z importem tych klas. Statyczne metody get_day_of_week i get_python_day_of_week z modułu Term dla porządku przeniosłam do pliku common/days_of_week.py, a metodę get_day_of_week z ChangedDay przemianowałam na get_official_day_of_week.
Na swoim miejscu pozostał import django.contrib.auth.models w pliku users/apps.py, który prawdopodobnie musi się znajdować wewnątrz funkcji ready.
Co do importów zakończonych komentarzem # noqa - wyszukałam wszystkie miejsca, w których występują i tam, gdzie nie było to dospecyfikowane, ograniczyłam ich działanie do reguły F401 (imported but unused), jako że jest to jedyna reguła, którą te linie łamią.
Przejrzałam wszystkie pliki pod kątem innych importów zlokalizowanych niezgodnie regułami przy użyciu poleceń
grep -r -A 10000 '^.*class ' | grep '.*import ',grep -r -A 10000 '^.*def ' | grep '.*import ',grep 'import ' $(grep -rL 'class')orazgrep 'import ' $(grep -rL 'def ')(uznając słowa kluczoweclassidefza pewną granicę między importami z początku pliku a jego resztą) i nie wykazały one żadnych anomalii poza tymi wymienionymi w issue #1620. W plikach tych przeniosłam wszystkie importy na początek tychże plików, ponieważ nie znalazłam żadnego uzasadnienia, żeby musiały tam pozostać.Dodatkowo, w pliku
schedule/models/event.pyzmieniłam zapytaniaTerm.objects.filter(event=self)naself.term_set.all()w celu wyeliminowania importuTermw tym module.Natomiast w aplikacji
enrollmentprzeniosłamChangedDayorazFreedaydo osobnego plikuspecialdays.py, żeby uniknąć problemów z importem tych klas. Statyczne metodyget_day_of_weekiget_python_day_of_weekz modułuTermdla porządku przeniosłam do plikucommon/days_of_week.py, a metodęget_day_of_weekzChangedDayprzemianowałam naget_official_day_of_week.Na swoim miejscu pozostał import
django.contrib.auth.modelsw plikuusers/apps.py, który prawdopodobnie musi się znajdować wewnątrz funkcjiready.Co do importów zakończonych komentarzem
# noqa- wyszukałam wszystkie miejsca, w których występują i tam, gdzie nie było to dospecyfikowane, ograniczyłam ich działanie do reguły F401 (imported but unused), jako że jest to jedyna reguła, którą te linie łamią.