Python. К вершинам мастерства это на русском. А в оригинале он, кажется, Fluent python. Только надо брать второе издание, первое уже порядком устарело.
А там фишка вроде такая, что уже в версии 1.4 старый ORM синтаксис поддерживается в синхронном варианте как deprecated, а в асинхронном - вообще никак. Как я понял, в 2.0 они полностью заблочат старый стиль и для синхронного драйвера тоже.
Так что уже сейчас нет вообще смысла использовать олдскульный session.query.
У меня в текущем проекте вынужденно поддерживаются оба драйвера, но стиль запросов уже используется единый - новый. Как-то вот так это может выглядеть в синхронном варианте:
with mdl.session as session:
with session.begin():
query = select(
mdl.Passport.name.label('passport_name'), mdl.Passport.value
).filter(mdl.Passport.value >= 37)
results = session.execute(query)
for result in results:
print(result.passport_name, result.value)
А в асинхронном так:
async with mdl.async_session as session:
async with session.begin():
query = select(
mdl.Passport.name.label('passport_name'), mdl.Passport.value
).filter(mdl.Passport.value >= 37)
results = await session.execute(query)
for result in results:
print(result.passport_name, result.value)
И в 2.0, как я понимаю, все это будет работать аналогично.
Смысла большого, конечно, нет, но специально поддерживать в приложении еще и синхронный драйвер, чтобы только создать табличку, как-то избыточно. Другое дело, если у вас, например, асинхронный вариант алхимии и плюс нужен алембик. Тогда да, имеет смысл держать синхронный драйвер чисто для алембика, во всяком случае я другого варианта не вижу.
Tldr; aiologger is only fully async when logging to stdout/stderr. If you log into files on disk you are not being fully async and will be using ThThreads.Ка
Как вы заметили, в моем примере вывод осуществляется именно в стандартный поток. Более того, я глубоко убеждён, что логирование в файл средствами языка - это плохая практика в принципе. Не дело приложения определять где и как хранить логи.
Что касается sqlite, то здесь все просто. Статья учебная и перегружать текст подробностями установки и подключения к "настоящей" БД я посчитал излишним. Тут и к использованию SQL тоже можно прицепиться, ведь на практике в большинстве случаев применяется ORM. Но грузить тут новичка еще и SqlAlchemy - это уже запредельный перебор)
Истина, как обычно, где-то посередине. Видал и юношей со взором горящим, готовых разрушить до основания работающую систему во имя прогрессивной архитектуры имени очередного дядюшки Боба/Джо/Тома, видал и юзеров, агрессивно-комфортно себя ощущающих в зоопарке самописных утилиток а-ля "моя первая программа на Delphi" и обменом данных через блокнот. Фанатизм вреден в любой форме.
Это все проблемы подросткового периода профессионального развития. Будь ты хоть семи пядей во лбу, но пока у тебя практического опыта - 1,5 пет-проекта и ты претендуешь на стажерскую/джуновскую позицию, неизбежно будешь терпеть пренебрежительное отношение hr-ов и отчаянно сражаться с 100+ кандидатами на одну вакансию.
Совет простой - стиснуть зубы и потерпеть год-два на неинтересной, малооплачиваемой, но профильной (!) работе. Потом второй заход поиска, но уже позиционировать себя как мидла. Там все уже гораздо человечнее проходит)
То есть, если мы делаем await f(), значит обозначаем точку переключения, а если просто f(), то неявно оборачиваем корутину в задачу? Ну, в принципе такой синтаксический сахар наверно имеет право на жизнь. Становитесь контрибьютором питона и попробуйте реализовать)
В учебном материале нецелесообразно, я считаю. При знакомстве с конкурентными вычислениями важно видеть процесс в динамике: что отработало быстро, что притормозилось, а что выполнилось как-бы одновременно. Если расставить повсюду временные метки и выводить в консоль тонны текста, то вся это мерцающая красота исчезнет) Ну а так да, в реальном приложении организуйте логирование и спокойно анализируйте бенчмарки постфактум.
Ну, тут уж ничего не поделаешь. Обратная совместимость - больное место asyncio. Я рассчитываю, что статья проживет долго, поэтому использую конструкции, рекомендованные для самой новой доступной версии питона.
Учиться вообще лучше на актуальном, мне кажется. Когда набьешь руку, разобраться в старых конструкциях уже не составляет проблемы.
Когда я работал в продажах, меня на собеседованиях обильно спрашивали про этапы продаж по Рысеву и Бакшту и методику СПИН. Правда, лучшие продавцы, которых я видел, не особо заморачивались в реальной жизни высокой теорией. Они просто продавали в 2-3 раза больше своих коллег по офису. Хотя были совсем не против и съездить на модный семинар, конечно. Но относились к этому с известной долей юмора.
Меня все-же больше беспокоит, что половина приходящих на стажировку студентов последнего курса не имеют представления о git и впадает в суеверный ужас от необходимости сделать что-то элементарное в командной строке. Концепцию big-O на интуитивном уровне так или иначе понимают почти все, только большинство как умные собачки - понимать понимают, но рассказать не могут.
Рискую нахватать минусов от пуристов, но, по-моему, важность знания кандидатом 20+ алгоритмов сортировки традиционно несколько преувеличена. С таким же успехом мы могли бы требовать от соискателя умения играть в шахматы (или еще лучше в го). Это тоже некоторым косвенным образом характеризует уровень логического мышления и усидчивость, но большого практического значения не имеет. Если вы не разработчик шахматных движков, конечно.
Python. К вершинам мастерства это на русском. А в оригинале он, кажется, Fluent python. Только надо брать второе издание, первое уже порядком устарело.
Когда станет скучно с Фаулером, подружитесь с Рамальо. Снова все станет непонятно и чудесато) Но читать надо, и не только про asyncio.
А там фишка вроде такая, что уже в версии 1.4 старый ORM синтаксис поддерживается в синхронном варианте как deprecated, а в асинхронном - вообще никак. Как я понял, в 2.0 они полностью заблочат старый стиль и для синхронного драйвера тоже.
Так что уже сейчас нет вообще смысла использовать олдскульный session.query.
У меня в текущем проекте вынужденно поддерживаются оба драйвера, но стиль запросов уже используется единый - новый. Как-то вот так это может выглядеть в синхронном варианте:
А в асинхронном так:
И в 2.0, как я понимаю, все это будет работать аналогично.
О, круто, спасибо! Попробую.
Смысла большого, конечно, нет, но специально поддерживать в приложении еще и синхронный драйвер, чтобы только создать табличку, как-то избыточно. Другое дело, если у вас, например, асинхронный вариант алхимии и плюс нужен алембик. Тогда да, имеет смысл держать синхронный драйвер чисто для алембика, во всяком случае я другого варианта не вижу.
Спасибо за критику.
Относительно aiologger читаем:
Как вы заметили, в моем примере вывод осуществляется именно в стандартный поток. Более того, я глубоко убеждён, что логирование в файл средствами языка - это плохая практика в принципе. Не дело приложения определять где и как хранить логи.
Что касается sqlite, то здесь все просто. Статья учебная и перегружать текст подробностями установки и подключения к "настоящей" БД я посчитал излишним. Тут и к использованию SQL тоже можно прицепиться, ведь на практике в большинстве случаев применяется ORM. Но грузить тут новичка еще и SqlAlchemy - это уже запредельный перебор)
Да, совершенно верно. Канонически верное применение единой сессии для всего приложения показано здесь.
Вот здесь посмотрите. И как запустить это под uvicorn тут.
Истина, как обычно, где-то посередине. Видал и юношей со взором горящим, готовых разрушить до основания работающую систему во имя прогрессивной архитектуры имени очередного дядюшки Боба/Джо/Тома, видал и юзеров, агрессивно-комфортно себя ощущающих в зоопарке самописных утилиток а-ля "моя первая программа на Delphi" и обменом данных через блокнот. Фанатизм вреден в любой форме.
Это все проблемы подросткового периода профессионального развития. Будь ты хоть семи пядей во лбу, но пока у тебя практического опыта - 1,5 пет-проекта и ты претендуешь на стажерскую/джуновскую позицию, неизбежно будешь терпеть пренебрежительное отношение hr-ов и отчаянно сражаться с 100+ кандидатами на одну вакансию.
Совет простой - стиснуть зубы и потерпеть год-два на неинтересной, малооплачиваемой, но профильной (!) работе. Потом второй заход поиска, но уже позиционировать себя как мидла. Там все уже гораздо человечнее проходит)
Спасибо, согласен. Поправил.
Спасибо за ценное замечание! Действительно, мой косяк - надо внимательнее читать документацию. Поправил и плюс в карму.
Вот именно этого я и добивался) Не запуская код невозможно чему-то научиться. Удачи!
То есть, если мы делаем await f(), значит обозначаем точку переключения, а если просто f(), то неявно оборачиваем корутину в задачу? Ну, в принципе такой синтаксический сахар наверно имеет право на жизнь. Становитесь контрибьютором питона и попробуйте реализовать)
async def my_breakfast():
print('поставил варить яйцо')
await asyncio.sleep(300)
print('съел яйцо')
#
async def your_breakfast():
print('поставил варить яйцо')
await asyncio.sleep(300)
print('съел яйцо')
Если бы создатели asyncio согласились бы с вашим предложением, мы бы с вами позавтракали очень быстро, но сырыми яйцами, к сожалению...
В учебном материале нецелесообразно, я считаю. При знакомстве с конкурентными вычислениями важно видеть процесс в динамике: что отработало быстро, что притормозилось, а что выполнилось как-бы одновременно. Если расставить повсюду временные метки и выводить в консоль тонны текста, то вся это мерцающая красота исчезнет) Ну а так да, в реальном приложении организуйте логирование и спокойно анализируйте бенчмарки постфактум.
Ну, тут уж ничего не поделаешь. Обратная совместимость - больное место asyncio. Я рассчитываю, что статья проживет долго, поэтому использую конструкции, рекомендованные для самой новой доступной версии питона.
Учиться вообще лучше на актуальном, мне кажется. Когда набьешь руку, разобраться в старых конструкциях уже не составляет проблемы.
У вас какая версия python? Попробуйте 3.10
Когда я работал в продажах, меня на собеседованиях обильно спрашивали про этапы продаж по Рысеву и Бакшту и методику СПИН. Правда, лучшие продавцы, которых я видел, не особо заморачивались в реальной жизни высокой теорией. Они просто продавали в 2-3 раза больше своих коллег по офису. Хотя были совсем не против и съездить на модный семинар, конечно. Но относились к этому с известной долей юмора.
Меня все-же больше беспокоит, что половина приходящих на стажировку студентов последнего курса не имеют представления о git и впадает в суеверный ужас от необходимости сделать что-то элементарное в командной строке. Концепцию big-O на интуитивном уровне так или иначе понимают почти все, только большинство как умные собачки - понимать понимают, но рассказать не могут.
Рискую нахватать минусов от пуристов, но, по-моему, важность знания кандидатом 20+ алгоритмов сортировки традиционно несколько преувеличена. С таким же успехом мы могли бы требовать от соискателя умения играть в шахматы (или еще лучше в го). Это тоже некоторым косвенным образом характеризует уровень логического мышления и усидчивость, но большого практического значения не имеет. Если вы не разработчик шахматных движков, конечно.