Немного не понял, т.е. вы нашли во всей книжки 2, возможно не совершенных примера кода, вырвали их из контекста, в результате чего стало не понятно, что эти примеры демонстрировали и на этом написали "разгромную" статью?
Насколько я помню, i/o bound задачи норм масштабируются через потоки, согласен, что это не совсем асинхронность, в понимании asyncio, но тем не менее, это по-моему рабочее решение. Если не ошибаюсь работа с файлами в асинхронище реализована так же.
Я честно говоря только "вкатываюсь в IT", поэтому пусть более опытные ребята поправят, но:
выражение "Годы разработки на Go выработали во мне приятное убеждение: компилируется – значит работает" - на мой взгляд далеко от реальности, статическая типизация только гарантирует, что вы типы не перепутали, а совсем не проверяет логику и никак не "устраняет необходимость тестирования"
Немного пробовал писать на java и строгая типизация - это кошмар в плане количества кода, которое будет делать то же действие, что и python. В некоторых случаях, на мой взгляд, грамотное название функций и doc-string - выглядят более качественным решением.
Мне до сих пор интересно, никто не проводил исследования какое количество ошибок в разработке "решает" строгая типизация, потому что, я бы не удивился, если "цена" за устранение ошибок - окажется слишком высокой. В данном случаи рассматривается "гипотетический вариант", что типизация нужна - чтобы убрать ошибки.
Вообще штука интересная, попробовал, генерацию доков:
Закинул такую процедуру,
def check_param_is_present_and_is_not_none(request:Request, param:List[str]) -> Tuple[bool, Optional[Response]]:
array_error = []
succes = True
for elem in param:
if elem not in request.query_params or request.query_params.get(elem, None) is None:
succes = False
array_error.append(f'Param "{elem}" is not present or empty')
resp = None if succes else Response(", ".join(array_error), status=status.HTTP_400_BAD_REQUEST)
return succes, resp
Получил, такое описание
""" Check if the parameters are present and not empty.
:param request: The request object
:type request: Request
:param param: The list of parameters to check
:type param: List[str]
:return: A tuple with a boolean and a response object
Не согласен, я думаю парень поймет, что после прочтения книжки за 500 рэ, получил знаний побольше курсов, за сколько-то там рэ, ну и можно ему это прям объяснить, если он сам не "схватит".
Все-таки радиоспектакли, я имею ввиду хорошие )), вещь отличная. Значительно лучше воспринимаются чем аудиокниги, слушал Солярис, с Арменом Джигарханьяном, потрясающая вещь. Спасибо всем, кто над ними работал!!!
Тоже проходил этот курс, понравился, но я так понял сильно зависит от наставников.
Немного не понял, т.е. вы нашли во всей книжки 2, возможно не совершенных примера кода, вырвали их из контекста, в результате чего стало не понятно, что эти примеры демонстрировали и на этом написали "разгромную" статью?
Насколько я помню, i/o bound задачи норм масштабируются через потоки, согласен, что это не совсем асинхронность, в понимании asyncio, но тем не менее, это по-моему рабочее решение. Если не ошибаюсь работа с файлами в асинхронище реализована так же.
ИИ кругом, осталось понять, как эффективно его применять.
я думаю сюда еще могут добавиться геополитические причины, как в нашей стране или в том же Китае.
Вообще странно, а в чем было неудобство, обычно как раз разделение удобней:
Позволяет работать с кодом не создавая конфликтов, т.к. по файлам реже пересекаетесь
Значительно удобней когда тебе надо править бизнес-логику, посмотреть один класс чисто по ней, а не бегать по одному большому файлу.
Ну и про развитие классов с их подменой, тоже проще когда они в отдельных файлах.
А можете подсказать название книги, а то google не в курсе по Рамальо?
Рассматривать колонку - как средство "наказания" - это прям свежий взгляд на нее ))
Честно говоря задумывался о колонке, но после того как яндекс решил вкрутить туда рекламу - реши, что все-таки не стоит )
Я честно говоря только "вкатываюсь в IT", поэтому пусть более опытные ребята поправят, но:
выражение "Годы разработки на Go выработали во мне приятное убеждение: компилируется – значит работает" - на мой взгляд далеко от реальности, статическая типизация только гарантирует, что вы типы не перепутали, а совсем не проверяет логику и никак не "устраняет необходимость тестирования"
Немного пробовал писать на java и строгая типизация - это кошмар в плане количества кода, которое будет делать то же действие, что и python. В некоторых случаях, на мой взгляд, грамотное название функций и doc-string - выглядят более качественным решением.
Мне до сих пор интересно, никто не проводил исследования какое количество ошибок в разработке "решает" строгая типизация, потому что, я бы не удивился, если "цена" за устранение ошибок - окажется слишком высокой. В данном случаи рассматривается "гипотетический вариант", что типизация нужна - чтобы убрать ошибки.
Главное джунам не показывать эту статью.. а то они решать эти хаки и фичи в прод запустить )))
Был на вашем бесплатном курсе по бэкенд, было интересно. Спасибо!
Вообще штука интересная, попробовал, генерацию доков:
Закинул такую процедуру,
Получил, такое описание
На мой взгляд, сетка вполне разобралась в коде ))
Не согласен, я думаю парень поймет, что после прочтения книжки за 500 рэ, получил знаний побольше курсов, за сколько-то там рэ, ну и можно ему это прям объяснить, если он сам не "схватит".
Интересно не столько по логгеру, сколько по декораторам..