Про "нет интерфейсов" это конечно сильное заявление. Я уж молчу про Протоколы и Дженерики. Но чем "__iter__" , "__len__" , "__str__", etc, не интерфейсы? Реализация любых из этих интерфейсов даёт возможности использовать стандартные конструкции и builtin функции для взаимодействия с объектами, будь то итерция или доступ к значениям через словарные скобки, сравнение, и т.д.
Автору явно надо углубить свои знания по питону прежде чем писать такое.
Ничего не нашли наверное потому, что это какое то извращение, уж простите за откровение. Незнаю что значит "тяжёлые" данные, но могу предположить что это их размер и если так то вы наверное вкурсе что в кафку сообщения больше одного метра складывать нельзя, так как она начинает жутко тормозить.
Ну наверное отправляется запрос на который создаётся тикет к которой привязывается какая нить бекграунд задача, уникальный номер тикета возвращается клиенту моментально, и клиент в свою очередь ждёт пока бекграунд таска выполняться и сможет вернуть результат. Клиент по уникальному ид тикета на запрос /poll эндпоинта как раз это и проверяет, готов результат или нет.
Эм я может что то путаю, но открытие файла так же как и его чтение в питоне не является асинхронной операцией, т.е. все эти корутины будут выполнены последовательно а не конкурентно. Может стоило ради примера использовать код (и библиотеки типа aiohttp или httpx) который бы скачивал какие то данные по сети?
Поработав с питоном, для себя, пришёл к выводу, что писать тесты на стандартной библиотеке крайне не удобно. Как пример если функция имеет ветвления, сразу получается что надо написать N тестов с одинаковым вызовом функции и разными входными и (возможно) выходными данными. Код тестов превращается в злостную копипасту. Другое дело pytest с его параметризованными тестами и фикстурами. Получается что нужно написать один тест и скармливать ему разные данные, что очень удобно и просто поддерживать.
Ещё одно это сам стиль тестов при работе с unittest либой, обязательное наследование и как следствие все тесты объединены в классы. Pytest же не накладывает таких ограничений и всегда можно писать тесты без указания классов просто объеденяя их в модули и легко перенося в случае рефакторинга.
ага слышал про subTest, не довелось использовать так как при запуске через pytest тестов написанных с помощью unittest (да так можно) есть ограничение по запуску тестов в несколько потоков. Но думаю в основном рабочая алтернатива параметризации в pytest.
Спасибо за статью. Не знаю насколько возбраняются циклы в тестах, но некоторые неудобства они могут принести если к примеру первый и последний элементы ошибочны то проверить все за раз не получится, придётся сначала исправлять первый кейс, прогонять по новой, увидеть что ещё один кейс сломан и исправлять код для него и т.д. Мне кажется юниттест библиотека питона не сильно гибкая в настройке, как pytest. Стиль тестов в pytest позволяет использовать параметризованные тесты и фикстуры, а так же не размазывать tearDown в отдельной функции а хранить всё рядом с объектом к которому он относится используя генератор для фикстур. Плюс сам тест выглядит как просто функция, не зависящая от классов. Один раз попробовав pytest обратно уже не смог вернуться к стандартной библиотеке. 😀
Дисковое пространство для почты даже в 500 мегабайт не такая уж проблема. Переписки вряд ли должны хранится в почте всё время, важные и старые можно убирать в архив, сохранять вложения на диск а сами письма удалять(может сохранив версию письма рядом с вложением если нужно)
Вроде вещь хорошая, но хотелось спросить, почему код написан так не аккуратно?
1. Где аннотации для типов?
2. Почему вы создаёте свойства не через декоратор? Вроде как код становится красивее сразу, чем вызывать функцию и писать лямбду внутри.
3. Класс __iterator только усложняет понимание происходящего внутри Playlist. Можно обойтись генератором внутри __iter__ метода. Судя по тому что __tracks, всего лишь список, то __iter__ внутри Playlist может выглядеть так
return iter(self.__tracks)
Ну и как бонус __getitem__ тоже уже не нужен будет.
4. Инициализировать атрибуты класса, как у вас в классе MusicProvider, дефолтными изменяемыми объектами вроде списков или словарей это грубейшая ошибка. Вроде во всех книгах по питону это проходися ещё при знакомстве с функциями. Лучше изменить на None и если ничего не передано то менять внутри __init__ на пустой список.
Про "нет интерфейсов" это конечно сильное заявление. Я уж молчу про Протоколы и Дженерики. Но чем "__iter__" , "__len__" , "__str__", etc, не интерфейсы? Реализация любых из этих интерфейсов даёт возможности использовать стандартные конструкции и builtin функции для взаимодействия с объектами, будь то итерция или доступ к значениям через словарные скобки, сравнение, и т.д.
Автору явно надо углубить свои знания по питону прежде чем писать такое.
Ничего не нашли наверное потому, что это какое то извращение, уж простите за откровение. Незнаю что значит "тяжёлые" данные, но могу предположить что это их размер и если так то вы наверное вкурсе что в кафку сообщения больше одного метра складывать нельзя, так как она начинает жутко тормозить.
Ну наверное отправляется запрос на который создаётся тикет к которой привязывается какая нить бекграунд задача, уникальный номер тикета возвращается клиенту моментально, и клиент в свою очередь ждёт пока бекграунд таска выполняться и сможет вернуть результат. Клиент по уникальному ид тикета на запрос /poll эндпоинта как раз это и проверяет, готов результат или нет.
Эм я может что то путаю, но открытие файла так же как и его чтение в питоне не является асинхронной операцией, т.е. все эти корутины будут выполнены последовательно а не конкурентно. Может стоило ради примера использовать код (и библиотеки типа aiohttp или httpx) который бы скачивал какие то данные по сети?
Поработав с питоном, для себя, пришёл к выводу, что писать тесты на стандартной библиотеке крайне не удобно. Как пример если функция имеет ветвления, сразу получается что надо написать N тестов с одинаковым вызовом функции и разными входными и (возможно) выходными данными. Код тестов превращается в злостную копипасту. Другое дело pytest с его параметризованными тестами и фикстурами. Получается что нужно написать один тест и скармливать ему разные данные, что очень удобно и просто поддерживать.
Ещё одно это сам стиль тестов при работе с unittest либой, обязательное наследование и как следствие все тесты объединены в классы. Pytest же не накладывает таких ограничений и всегда можно писать тесты без указания классов просто объеденяя их в модули и легко перенося в случае рефакторинга.
Он там вроде от слияния получит лямов 200+
охотно верим
ага слышал про subTest, не довелось использовать так как при запуске через pytest тестов написанных с помощью unittest (да так можно) есть ограничение по запуску тестов в несколько потоков. Но думаю в основном рабочая алтернатива параметризации в pytest.
Спасибо за статью. Не знаю насколько возбраняются циклы в тестах, но некоторые неудобства они могут принести если к примеру первый и последний элементы ошибочны то проверить все за раз не получится, придётся сначала исправлять первый кейс, прогонять по новой, увидеть что ещё один кейс сломан и исправлять код для него и т.д. Мне кажется юниттест библиотека питона не сильно гибкая в настройке, как pytest. Стиль тестов в pytest позволяет использовать параметризованные тесты и фикстуры, а так же не размазывать tearDown в отдельной функции а хранить всё рядом с объектом к которому он относится используя генератор для фикстур. Плюс сам тест выглядит как просто функция, не зависящая от классов. Один раз попробовав pytest обратно уже не смог вернуться к стандартной библиотеке. 😀
Дисковое пространство для почты даже в 500 мегабайт не такая уж проблема. Переписки вряд ли должны хранится в почте всё время, важные и старые можно убирать в архив, сохранять вложения на диск а сами письма удалять(может сохранив версию письма рядом с вложением если нужно)
1. Где аннотации для типов?
2. Почему вы создаёте свойства не через декоратор? Вроде как код становится красивее сразу, чем вызывать функцию и писать лямбду внутри.
3. Класс __iterator только усложняет понимание происходящего внутри Playlist. Можно обойтись генератором внутри __iter__ метода. Судя по тому что __tracks, всего лишь список, то __iter__ внутри Playlist может выглядеть так
Ну и как бонус __getitem__ тоже уже не нужен будет.
4. Инициализировать атрибуты класса, как у вас в классе MusicProvider, дефолтными изменяемыми объектами вроде списков или словарей это грубейшая ошибка. Вроде во всех книгах по питону это проходися ещё при знакомстве с функциями. Лучше изменить на None и если ничего не передано то менять внутри __init__ на пустой список.
5. bitbucket.org/gudvinr/spothiefy/src/9de32ba7a83f5698042dc94b34d1efebea1528c3/spothiefy.py#lines-60 вот тут вообще не понятно, присваивание, ниже новое присваивание, а что если длина словаря больше 1?
И ещё обычно считается что __init__ это легковестная операция, т.е. там не должно быть каких то I/O вызовов как у вас…
Это что сразу бросилось в глаза.