Питонические атаки

Кстати, в честь этой кампании по сбору средств, JetBrains снова открыли свою акцию — покупаешь PyCharm с хорошей скидкой в 30%, а все собранные средства отправляются прямиком в PSF. Актуально до 1 декабря! Звучит примерно как «покупайте наш наркотик, а все деньги с вашей первой дозы мы переведём голодающим африканским детям»😅 Шучу, конечно. Инициатива крайне правильная. Я искренне уважаю JetBrains за то, что они активно участвуют в жизни сообществ многих ЯП. И наркотик у них качественный, я уже давно сижу. Оно явно стоит своих денег. Но нужно понимать, что это просто лишь ещё один способ расширить пользовательскую базу. В прочем, почему бы и нет, это ведь идёт на пользу всем. https://lp.jetbrains.com/support-python/ UPD: будьте внимательны, эта акция не применяется для продления уже активных подписок, только для новых! #jetbrains

PSF заплатите чеканной монетой, чеканной монетой, о-о-о. Зачтётся все это, зачтётся все это! Говорят, чтобы поддерживать нынешние инициативы на плаву (developer in residence, packaging), нужно 325 тыс. долларов в год. Чтобы нанять ещё людей, нужно уже 500+. Конечно, спонсоры, типа Google, Microsoft и Bloomberg, здорово выручают и помогают собрать хорошую долю от этой суммы, но всё равно каждая копеечка имеет значение. Python всё-таки community language, так что было бы здорово и обычным рядовым пользователям немного скинуться. Even if donations are a portion of the PSF's revenue, every dollar makes an impact and allows the PSF financial stability to continue supporting a growing community! https://www.python.org/psf/donations/2021-q4-drive/

Интересный побочный эффект принесло одно из изменений в Python 3.10 — каноничный пример про состояние гонки (race condition) между потоками перестал работать! Операция += (INPLACE_ADD) стала чуть-чуть более атомарной. Полагаться на это поведение, конечно же, нельзя, потому что оно может измениться в любой момент. https://stackoverflow.com/q/69993959/10650942

Доказательство Тьюринг-полноты однострочников на Python #habr #python #python #ненормальное_программирование #python #тьюринг_полнота #доказательство #написание_кода #плохой_код #ненормальное_программирование #развлечения

okay.... https://susam.in/maze/infinitely-nested-dictionary.html

Вывод: стало быстрее, а почему — я не понял 🤷‍♂️

Всячески рекомендую ютуб-канал "Диджитализируй!". Он периодически снимает классные видео про Python. А сегодня я нашёл там настолько полезное видео, что решил даже запостить его сюда, чтобы в следующий раз, когда беда вдруг снова внезапно меня настигнет, оно было под рукой. https://www.youtube.com/watch?v=Q1RUYQIgVKM #vim

Surprisingly at the top of that curve is again 'no types' https://twitter.com/fasterthanlime/status/1248025337235210243?s=20 #meme

There should be one-- and preferably only one --obvious way to do it.

А какие ещё вы знаете примеры нарушения этого принципа? Желательно в стандартной библиотеке.

«Прежде всего, дзен Python говорит, что любое решение должно быть единственное. Поэтому в Python всего минимум по три.»

В связи с чем проект Django собирается начать форматировать свой код при помощи black. Этот автоформаттер постепенно становится де-факто стандартом оформления кода. Но кажется, что Django будет первым проектом такого масштаба, который решил «очернить» свой код. https://twitter.com/adamchainz/status/1455850491519254531?s=21 #black #django

Автоформаттер black принял «политику стабильности». В 2022 ожидайте стабильный релиз. https://twitter.com/llanga/status/1455496802812239876?s=21 #black

Обсуждения выпиливания GIL продолжаются. Недавно Гвидо создал тред по поводу библиотек с нативным кодом, которые никак не защищают свои внутренние данные от других потоков и просто полагаются на наличие GIL, который исключит возможность одновременного доступа к данным. Таких библиотек много, и они начнут ломаться разными неожиданными способами, если просто отнять у них GIL. Нужно найти такой подход, чтобы они не сломались и тем самым не создали ещё одну несовместимую версию языка (никто не хочет повторения истории с 2->3). То, что уже обсуждаются уже конкретные детали плана, заставляет меня верить, что в основном идея удаления GIL обсуждена и принята. https://discuss.python.org/t/nogil-mode-and-extensions/11546/11 #gil

Ваш питон тоже проверяет ваш код?)

Выполняем:

$ pip install postgresql-wheel

И теперь у нас в виртуальном окружении есть полноценный PostgreSQL! Изолированный, уже скомпилированный. Для установки не потребовалось sudo. Теперь можно программно запускать и удалять сервера БД. Полезно, например, для тестов, когда тесты сами могут создать себе такую базу, которая им нужна, сделать своё дело и замести все следы. В комплекте даже есть фикстура для pytest. Сборки пока что публикуются только для Linux, следовательно, на других ОС это работать не будет. https://github.com/michelp/postgresql-wheel

Классическая статья про DI от Мартина Фаулера. https://martinfowler.com/articles/injection.html #dependency_injection

Доклад про инъекцию зависимостей в питоне от создателя dependency_injector. https://www.youtube.com/watch?v=mJI7MzRCVkQ #dependency_injection

Воскрешу из сохранённых сообщений конспект доклада с Python Community Meetup, который я посмотрел аж ещё в августе. Владислав Лаухин — Применение Dependency Injection в Python https://youtu.be/qfMWyStoyS4?t=3300 * Dependency Injection — полезный подход, но в Python-сообществе эта тема недооценена, потому что у нас (наверное, по историческим причинам) устоялись другие практики. Например, Django и Flask — самые популярные веб-фреймворки, не используют этот подход вообще, он не упоминается в документации, поэтому многие питонисты про такое могут даже не знать. Вместо этого у нас в ходу глобальные переменные, которые импортируются из всяких неожиданных мест. * В терминах и аббревиатурах тоже есть путаница и непонимание: Dependency Inversion, Inversion of Control и Dependency Injection — это разные вещи. * Dependency Injection (дальше просто DI) уменьшает связанность кода в системе, делает его гибче, расширяемее, его становится легче изменять и покрывать тестами. * DI не стоит использовать везде. Например, это не нужно в исследовательских проектах (RnD), прототипах и небольших скриптах. Легаси-код переписывать на DI тоже не всегда обоснованно, усилия могут не окупиться. * Встроенная система зависимостей в FastAPI отлично реализует принцип DI и решает проблемы, пользуйтесь ей. Однако, если вы пишете не HTTP API, вам придётся искать другой способ внедрять зависимости. * Докладчик с командой попробовали несколько реализаций DI на Python, но остановились на dependency_injector, и им очень нравится. Внедрили уже в половину своих проектов. Не всё идеально, но плюсы перевешивают минусы. * Тесты стали значительно проще. Уменьшилось количество манкипатч/моков, благодаря чему тесты перестали ломаться сотнями штук от каждого рефакторинга. * Выводы: DI — круто, dependency_injector — огонь, тестировать код — важно. #конспект #dependency_injection