Попробуйте зайти в тот же Whatsapp и скопировать часть сообщения, а не его целиком. Тг более функциональна и удобна чем большинство других мессенджеров. Вк последнее время так вообще тг копирует
На рынке нет большого числа высококвалифицированных разработчиков уровня middle+ и выше с адекватными финансовыми ожиданиями.
Как мне нравится нежелание компаний повышать зп. Особенно при условии огромной инфляции, курса рубля.
Вижу как джунов без опыта нанимали за 100-150 и это год назад. А сейчас мидлу выше 200 платить не хотят. А сеньора хотят до 300. Естественно, что при таких зарплатах будет мало высококвалифицированных разработчиков
Twisted -- 2002 год. Tornado -- 2009 год. Python 3.5 -- 2015 год.
Ничего не могу сказать про Twisted, возможно там просто использовалось несколько потоков, а потом перешли на asyncio. А вообще идея asyncio была предоставлена Дэвидом Бизли в 2009 на Pycon. Изначально вместо ключевых слов async/await использовались итераторы
Может статья писалась ChatGPT потому что странно, что даже информация в самой статье противоречит друг другу
В этом посте я подробно расскажу о важной фиче, которая появилась в Python 3.5 — асинхронности
Неа, в python 3.5 завезли asyncio, а не асинхронность.
Есть разница между общим понятием асинхронности и asyncio. В общем понимании асинхронность это возможность выполнять несколько задач независимо. Это означает что асинхронность можно реализовать к примеру несколькими потоками. Только вот в случае потоков GIL будет переключаться между потоками и проверять надо ли ему работать или нет. asyncio решает эту проблему. В данной статье речь все же больше идет об asyncio
Модуль asyncio с методами async functions, async with, контексты и корутины — выбор средств асинхронности в Python неплохой. Комбинируя их, можно создавать программы с высокой параллельностью
asyncio это не про параллельность. В asyncio несколько задач не работают одновременно, пока одна задача ждет, другая может работать
Теперь поговорим об использовании асинхронности с популярными фреймворками — Django, Flask и FastAPI. Ни один из них не имеет встроенной поддержки асинхронности, но ее можно добавить с помощью внешних библиотек.
У FastAPI есть из коробки
С помощью ORM вы можете выполнять запросы к базе данных асинхронно, вместо того чтобы ждать ответа перед выполнением следующей задачи
Не обязательно с помощью ORM, ORM - это об удобстве работы и представлении данных в виде более сложных объектов, чем tuple/list/dict.
Так вы можете увеличить производительность приложения и оптимизировать использование ресурсов. Пример асинхронного подключения к СУБД:
Дальше идет пример. Я вот чего не понимаю, почему говорим про ORM, а используем сырые SQL-запросы?
Обработка запросов ускоряется
Не совсем так, скорее процессорное время тратится более оптимизировано. Если использовать синхронный запрос, он отработает скорее всего даже быстрее, если сразу начнет выполнятся. На практике запрос сначала попадает в очередь т.к. приложение способно одновременно обрабатывать к примеру только 4 запроса и начинает выполняться только тогда, когда приходит его очередь. В случае использования async/awit тоже есть очередь, но в момент IO задач приложение может взять новый запрос, что невозможно в случае с синхронным выполнением.
Не все базы данных поддерживают асинхронный режим работы — например реляционные базы данных, такие как PostgreSQL и MySQL.
Эмм, чего? Весь ввод/вывод это IO задачи, как там работают бд нам на самом деле и не важно.
При использовании таких баз данных с асинхронным кодом вам могут потребоваться специальные библиотеки типа asyncpg.
Это всего лишь способ подключения, базу данных при этом asyncpg магическим образом не превращает в другую
С тем же успехом мы можем сказать что ОС работает синхронно, потому что для удаления файлов есть os.remove
Мне кажется автору стоит разобраться в БД/ORM/Асинхронности/Asyncio
В примере не понятно какой тип id в пути. Это может быть как integer, так и uuid. Бывает и такое, что одновременно в проекте используются два типа. А если принимаем не json, а файл? Или возвращаем файл?
Я только за, когда появляются новые спецификации. В этой борьбе останутся только самые удобные, но предложенный вариант таким пока что не выглядит.
К примеру, в данном случае проще было написать схемы, которые валидирую json, а потом на основе них делать OpanAPI, так к примеру делает FastApi c схемами Pydantic. Программист в итоге описывает только кодом схемы, что сильно удобнее, чем писать руками. Думаю так же будет и при проектировании
Не соглашусь, я вот писал статью о том, как ChatGPT решила несколько задач около олимпиадного уровня.
Но соглашусь с коллегами ниже. Или нейросеть снесёт нафиг все ИТ профессии, что пока что, вряд-ли, или будет использоваться для написания каких-то алгоритмов/задач, которые не будут ломать бизнес логику. А вот программист уже будет думать как это встроить в проект, чтоб ничего не упало
Для разработки почему бы и нет? Когда у тебя много проектов, то очень удобно запустить бд для конкретно этого проекта одной командой, а потом так же быстро остановить
Обычно есть ограничения на количество отправок. В данном случае было 200. Но даже при увеличенном лимите перебрать все возможные варианты для прохождения тестов (большинство из которых закрыто и приходит только с вердиктом "неверно") выглядит как что-то маловероятное.
Если вы не в курсе, то существует отдельная профессия людей, которая занимается вычиткой текста. Не каждый человек знает все правила русского языка.
Даже профессиональные писатели прибегают к вычитке текста. Это не значит, что они не пишут текст. Я к тому, что все ошибки могут быть исправлены нейросетью. Теперь можно использовать ChatGPT для вычитки текста, вместо того чтобы делать это в Word или с помощью специальных людей.
Я через несколько дней после написания статьи тоже об этом подумал. В любом случае, из проведенного теста видно, что нейросеть сможет решить простые задачи. А к сложным, как минимум, накинет идеи и предложит неоптимальное решение.
Ну, и я сомневаюсь, что кто-то специально тренировал ChatGPT на олимпиадные задачи.
Попробуйте зайти в тот же Whatsapp и скопировать часть сообщения, а не его целиком. Тг более функциональна и удобна чем большинство других мессенджеров. Вк последнее время так вообще тг копирует
Как мне нравится нежелание компаний повышать зп. Особенно при условии огромной инфляции, курса рубля.
Вижу как джунов без опыта нанимали за 100-150 и это год назад. А сейчас мидлу выше 200 платить не хотят. А сеньора хотят до 300. Естественно, что при таких зарплатах будет мало высококвалифицированных разработчиков
Ничего не могу сказать про Twisted, возможно там просто использовалось несколько потоков, а потом перешли на asyncio. А вообще идея asyncio была предоставлена Дэвидом Бизли в 2009 на Pycon. Изначально вместо ключевых слов async/await использовались итераторы
Может статья писалась ChatGPT потому что странно, что даже информация в самой статье противоречит друг другу
Неа, в python 3.5 завезли asyncio, а не асинхронность.
Есть разница между общим понятием асинхронности и asyncio. В общем понимании асинхронность это возможность выполнять несколько задач независимо. Это означает что асинхронность можно реализовать к примеру несколькими потоками. Только вот в случае потоков GIL будет переключаться между потоками и проверять надо ли ему работать или нет. asyncio решает эту проблему. В данной статье речь все же больше идет об asyncio
asyncio это не про параллельность. В asyncio несколько задач не работают одновременно, пока одна задача ждет, другая может работать
У FastAPI есть из коробки
Не обязательно с помощью ORM, ORM - это об удобстве работы и представлении данных в виде более сложных объектов, чем tuple/list/dict.
Дальше идет пример. Я вот чего не понимаю, почему говорим про ORM, а используем сырые SQL-запросы?
Не совсем так, скорее процессорное время тратится более оптимизировано. Если использовать синхронный запрос, он отработает скорее всего даже быстрее, если сразу начнет выполнятся. На практике запрос сначала попадает в очередь т.к. приложение способно одновременно обрабатывать к примеру только 4 запроса и начинает выполняться только тогда, когда приходит его очередь.
В случае использования async/awit тоже есть очередь, но в момент IO задач приложение может взять новый запрос, что невозможно в случае с синхронным выполнением.
Эмм, чего? Весь ввод/вывод это IO задачи, как там работают бд нам на самом деле и не важно.
Это всего лишь способ подключения, базу данных при этом asyncpg магическим образом не превращает в другую
С тем же успехом мы можем сказать что ОС работает синхронно, потому что для удаления файлов есть os.remove
Мне кажется автору стоит разобраться в БД/ORM/Асинхронности/Asyncio
В примере не понятно какой тип id в пути. Это может быть как integer, так и uuid. Бывает и такое, что одновременно в проекте используются два типа. А если принимаем не json, а файл? Или возвращаем файл?
Я только за, когда появляются новые спецификации. В этой борьбе останутся только самые удобные, но предложенный вариант таким пока что не выглядит.
К примеру, в данном случае проще было написать схемы, которые валидирую json, а потом на основе них делать OpanAPI, так к примеру делает FastApi c схемами Pydantic. Программист в итоге описывает только кодом схемы, что сильно удобнее, чем писать руками. Думаю так же будет и при проектировании
Возможно, я забыл загнать данный абзац в нейросеть, поэтому сейчас ChatGPT исправил этот и еще несколько других ошибок в куске текста
Не соглашусь, я вот писал статью о том, как ChatGPT решила несколько задач около олимпиадного уровня.
Но соглашусь с коллегами ниже. Или нейросеть снесёт нафиг все ИТ профессии, что пока что, вряд-ли, или будет использоваться для написания каких-то алгоритмов/задач, которые не будут ломать бизнес логику. А вот программист уже будет думать как это встроить в проект, чтоб ничего не упало
Для разработки почему бы и нет?
Когда у тебя много проектов, то очень удобно запустить бд для конкретно этого проекта одной командой, а потом так же быстро остановить
А в случае прода соглашусь
Обычно есть ограничения на количество отправок. В данном случае было 200. Но даже при увеличенном лимите перебрать все возможные варианты для прохождения тестов (большинство из которых закрыто и приходит только с вердиктом "неверно") выглядит как что-то маловероятное.
Если вы не в курсе, то существует отдельная профессия людей, которая занимается вычиткой текста. Не каждый человек знает все правила русского языка.
Даже профессиональные писатели прибегают к вычитке текста. Это не значит, что они не пишут текст. Я к тому, что все ошибки могут быть исправлены нейросетью. Теперь можно использовать ChatGPT для вычитки текста, вместо того чтобы делать это в Word или с помощью специальных людей.
Я через несколько дней после написания статьи тоже об этом подумал. В любом случае, из проведенного теста видно, что нейросеть сможет решить простые задачи. А к сложным, как минимум, накинет идеи и предложит неоптимальное решение.
Ну, и я сомневаюсь, что кто-то специально тренировал ChatGPT на олимпиадные задачи.