Комментарии 21
Я, конечно старпер и не использую match‑case, но мне кажется, что на картинке "до" и "после" не совсем эквивалент. Обмакните меня в ... и скажите, где справа проверка на tuple?
case host, port:Это и есть проверка на кортеж.
x = [1, 2, 3]
if isinstance(x, tuple) and len(x) == 2:
host, port = x
mode = "http"
elif isinstance(x, tuple) and len(x) == 3:
host, port, mode = x
print(host, port, mode) # не работает
match x:
case host, port:
mode = "http"
case host, port, mode:
pass
print(host, port, mode) # работаетэти 2 фрагмента не еквивалентны. А вот если убрать проверку на tuple, то работать будет. Но тогда пример у автора будет не таким красочным. Это просто зануда-мод
Пример из pep-а взят, так что продолбались авторы на неудачном примере.
И да, и нет. В оригинальном PEP 622 приводят пример из Django, где тестят и список, и кортеж. Но тут проверка на тип скорее для возможности дальше воспользоваться destructuring, чем необходимость явно запретить передавать всё кроме tuple и list.
We can see the shape analysis of the
valueat the top, following by the destructuring inside.
То есть здесь важна "форма", а не содержание =)
Ну, в примере проверки именно на тьюпл нет, в case сразу распарсивается некий массив (сидеть оказаться и списком) в переменные. Если распасивается в две переменные - первый кейс, если в три - во второй.
Спасибо за статью.
Лично мне пример с `Union[x, y]` и `x | y` не нравится: по мне Optional[str] кажется более выразительным, чтоли, чем `str | None`. Или тут имелось в виду _explicit is better than implicit_ ?)
ну так "str | None" читается буквально "строка или нан" - идеально
Никита Соболев может когда-нибудь подробнее расскажет, почему в итоге пришли к `int | None`. Если коротко, то надо привыкать к новому синтаксису, он победил.
Но `dict[str, str]()` в 3.12 коллеги из других языков мне лихим словом припоминают.
Довести nogil до конца планируется к 2030 году
а я еще думал в java глобальные фичи долго релизятся ;)
Вообще самая главная проблема зачем обновлять питон в проектах - требования ИБ
Я один раз знатно подгорел на крупном проекте, когда мне прилетела таска в стиле "обновить либу xxx с версии типа 7.5.123 на минимум 7.6 из-за security бага (ссылка на CVE)"
ну я подумал "приключение на 5 минут, туда и обратно" (с)
мне это приключение заняло месяц, кровавые слезы и срочный апдейт десятка микросервисов включивший в себя подъем версии питона и ядерного фреймворка и судорожной адаптации части кода под изменения пары десятков апи....я и до этого с отдельным пиететом относился к обновлениям с точки зрения безопасности, а тут на собственной шкуре испытал что бывает если забить на обновление версий библиотек
вобщем чё получилось, эта либа была в зависимостях у десятка других библиотек, которые использовались в библиотеке базовых подсистем которая использовалась во всех проектах компании...и её подъем на 1 минорную версию вызвал цепочку обновлений зависимостей в том числе и на мажорные версии либ, что потянуло за собой уже изменения в кодовой базе всех связанных проектов и в некоторых случаях вплоть до увеличения версии питона т.к. одна либа из зависимостей (гдето 3-4 уровня выше от той злосчастной либы) начала требовать более новый питон
по этому аргумент что новый питончик нужен потому что там фичи какието современные, на самом деле не так существенны, как проблемы которые могут возникнуть если ваш проект важен с точки зрения ИБ...
Такое ощущение что в вашем случае это был бессмысленный труд, так как из-за разных файерволов врядли можно было использовать уязвимость.
Вы помните баг с log4j? никакой фаерволл вам не поможет
или уязвимость в парсере pdf файлов например или в парсере json/xml
"разные фаерволлы" - штука такая себе, в них тоже бывают уязвимости... я видел своими глазами тест на проникновение когда взламывали на моих глазах систему где не был установлен один единственный патч вышедший 3 дня назад.
тут спасет только IDS и очень жесткие правила в межкоммуникациях внутренних, но по моей практике - тех кто так делает - очень ОЧЕНЬ мало. по этому постоянные обновления либ это обоснованное снижение рисков...
Не увилел чёткого ответа зачем обновлять Питон. Если проект прекрасно обходился без модных конструкций и синтаксического сахара, то зачем его обновлять?
Потому что - это модно, молодежно) А автор статьи - питон-евангелист. Разве не чувствуете, как он взахлёб новые фичи перечисляет. Я некоторые предложения не до конца понял, так все быстро. Шучу конечно)
А если серьезно, то очень странно, что две основные причины, ради которых обычно затевается это часто недешевое для бизнеса удовольствие, в статье не упомянуты. Это безопасность и исправление критичных ошибок. Выше уже написали про безопасность, security patches, уязвимости и вот это все. Так же часто обновляют, чтобы закрыть баги или какие-то вещи, которые работают не совсем, как должны или доставляют неудобства пользователям продукта или разработчикам. Ну и обновляться нужно своевременно, чтобы не получилось, как у автора комментария выше про больше месяца работы и много боли.
Статью надо было назвать вроде "Какие крутые вещи может предложить Python" или что-то в таком духе. А текущий заголовок и правда в статье не раскрыт.
Про эти причины лучше безопасники расскажут. Я именно с точки зрения разработчика хотел коротко осветить и поделиться полезными ссылками.
Вы же техлид. А это уже не простой разработчик. Видимо, в Яндексе есть отдельные люди, которые актуальность пакетов мониторят. Но в тех компаниях, в которых работал я, эти вопросы всегда входили в обязанность тех/тим лида. Иногда с консультацией со стороны безопасников или сторонней компании, которая аудит делает. Но всегда за это отвечал в первую очередь технический руководитель. И это нормально, ибо он лучше всех знает продукт, что там используется и какие решения могут представлять потенциальный вектор для атаки. Но если у вас этим отдельные люди занимаются, ну хорошо.
Работает — не трожь: зачем обновлять Python в долгоживущих проектах