mypy поможет уже начиная с момента, когда мы попытаемся передать times: str аргуметом в range(...), который ожидает int.
Но если говорить про момент с условием — mypy сообщит, что тут что-то не так:
app.py:19: error: Incompatible types in assignment (expression has type "Callable[[str, int], Any]", variable has type "Callable[[str, str], Any]")
Похоже, тут mypy видит, что одной и той же переменной передаются Callable с разными типами и он сразу же об этом сообщает.
Так же, насколько я понял, mypy делает предположение (так как он не может знать заранее что будет лежать в newInterface), что условие выполнится и в secret будет лежать функция greet_times2, которая на вход принимает str, str и не поднимает дополнительную тревога .
Если же присвоение функций в условии поменять местами (при выполнении условия в secret присвоится greet_times, который str, int), mypy даст знать, что мы еще и типами ошиблись:
app.py:22: error: Argument 2 has incompatible type "str"; expected "int"
В общем, штука мощная и прикольная. Неожиданно приятно, что малыми усилиями можно защитить себя от выстрелов в ногу даже в Питоне.
# app.py
name = "John"
times = "1"
def greet_times(name: str, times: int = 1):
for _ in range(times):
print(f"Greetings, {name}!")
greet_times(name, times)
secret = greet_times
secret(name, times)
mypy app.py найдет и сообщит мне о двух ошибках: как для оригинальной функции, так и для делегированной:
app.py:10: error: Argument 2 to "greet_times" has incompatible type "str"; expected "int"
app.py:13: error: Argument 2 has incompatible type "str"; expected "int"
На самом деле, они мощные и умеют сильно больше, чем пример выше.
Даже если немного начать типизировать код — это помогает. Это еще называют gradual typing.
Можно обрабатывать, но не обязательно. Этим занимается сторонний тайп-чекер (вроде mypy, который к слову, разрабатывается создателем Python).
Может показаться, что «для этого нужно стороннее решение», но это не так важно, так как mypy — самый используемый тайпчекер, стандарт дефакто и поставляется с любым плагином для среды разработки по Питону (VSCode тот же). В PyCharm есть свой. То есть, проверка типов встраивается очень приятно и без лишних телодвижений.
Часто читаю отзывы, что питонистам нравится Go и все не могу понять — почему?
Чем он вас цепляет после Питона?
Я хоть владею Питоном не профессионально, но даже учить Go и его особенности неприятно. Мне куда ближе тот же Kotlin.
Говорят, PEP по типизации располагает к созданию инструментов, которые бы использовали эти самые аннотации в целях улучшения производительности. Вот вдруг JIT нам прикрутят? :)
У неё есть пара недостатков:
… полное игнорирование второй версии Python… Последнее понятно и простительно...
Очень интересный "недостаток" в книге по Django 2.1, учитывая это:
Django 2.1 supports Python 3.5, 3.6, and 3.7. Django 2.0 is the last version to support Python 3.4. We highly recommend and only officially support the latest release of each series.
Согласитесь, выключать полезную функцию, когда нужно поделиться файлом со знакомым или по работе из-за того, что кто-то использует её не по назначению — не очень круто.
Для ваших целей есть специальные файловые хостинги с документированными лимитами. :)
Если человек покупает Яндекс.Смарфтон, то очень странно от него ожидать, что он захочет удалить Яндекс.Браузер. Ты уже или весь в этой экосистеме или непонятно зачем покупал.
Интересно, а какое ограничение допустимо для шаринга файлов?
Или вы решили Яндекс.Диском раздавать файлы сотням / тысячам людей? Не для этого же функция создавалась.
The precision is a decimal number indicating how many digits should be displayed after the decimal point for a floating point value formatted with 'f' and 'F', or before and after the decimal point for a floating point value formatted with 'g' or 'G'.
Если в код из примера после {precision} добавить f — получим 4 знака после запятой:
Абсолютно поддерживаю. Для API — отличный выбор. Действительно минималистичен и среди синхронных фреймворков является крайне быстрым (частично на Cython).
Еще сейчас активно разрабатывается Vibora — асинхронный веб-фреймворк, внутренности которого написаны на Cython, из-за чего он получился невероятно быстрым (на странице проекта есть относительно свежие бенчмарки). До production-ready ему далеко, но «звездочку» им поставил, однозначно стоит следить. :)
окружение все равно надо явно активировать через pipenv shell, поэтому не понимаю, чем pipenv shell отличается от. venv/bin/activate к примеру
Для установки пакетов НЕ нужно активировать окружение самому. Даже для запуска скриптов можно НЕ активировать окружение самому, а воспользоваться pipenv run <command>, чтобы исполнить что-нибудь из нужного окружения.
Я лишь предложил pyenv в качестве альтернативы
…
Начнем с того, что это разные инструменты
Так и запишем!
Еще раз. pipenv при желании расширяется возможностями pyenv. Зачем себя ограничивать pyenv, а остальные вещи делать руками или другими способами — непонятно.
pyenv же активирует окружение при входе в директорию проекта
На любой "платформе"? bash / zsh / cmd / powershell?
Автоматическую активацию окружения уже давно можно сделать и просто в pip, подключив нужный плагин в том же zsh. Такие же штуки есть и для pipenv.
Как использование хешей для файлов может оповестить о наличии или отсутствии уязвимостей в коде?
Никак, сори, я неправильно прочитал ваш комментарий. Я держал у себя в голове информацию об этом.
Просто непонятно тогда, что значит "Strongly encourage the use of the latest versions of dependencies"
Нет Pipfile.lock — всегда ставит последние версии пакетов, если не указано иначе.
если что-то, что выходит за рамки этого языка, то увы, тут pipenv будет только мешать этим функционалом, потому что в одном месте вы будете использовать стороннюю тулзу, а в проектах на питоне pipenv.
Не совсем понимаю, как тут будет мешать pipenv. Есть проект на Python, в нем есть свой .env, pipenv его подтянул. Никто не мешает использовать остальные тулзы.
pipenv позиционируется разработчиками именно как менеджер среды dev окружения "Python Dev Workflow for Humans"
Ну, это очевидно. Вы превращаете свой неудобный процесс разработки в удобный. :)
А при использовании его только в дев окружении теряется весь смысл, потому что на прод деплоится это будет уже по-другому.
Ничего не теряется. Даже если вы будете собирать свое приложение в Докере — вам так или иначе нужны конкретные версии пакетов, которые будут лежать в Pipfile.lock. А его уже разработчик будет создавать при помощи pipenv с великим удовольствием.
Конечно, это невероятно упрощает работу. Раньше нужно было делать несколько вещей и следить за ними самому (где создавался venv, активировал ли я его), а тут всё сделали за меня.
поставьте pyenv, он решает эту проблему, да еще и добавляет возможность ставить любую версию питона и на базе него создавать окружения
Поставить инструмент хуже, чем инструмент лучше? Странное предложение. Тем более, что pipenv умеет использовать pyenv, поэтому минусов никаких на выходе не получаем.
Но это решается и без pipenv. Может и не так элегантно) Но ставить только для этого отдельную тулзу как-то избыточно, что ли.
Нет, не избыточно. Это автоматизация рутинного процесса в инструменте, который я буду использовать каждый день. И другие разработчики тоже. А то все городят свой костыль.
От установки изначально неправильного или подмененного пакета это никак не защищает.
А суть фичи не в этом, а в том, чтобы оповещать разработчика о версиях пакетов, которые известны наличием уязвимостей. Это круто. Лучше когда оно есть, чем когда нет, согласитесь.
. С одной стороны, ребята пишут, что жестко пинят версии, а потом пишут, что поощряют использовать самые последние версии зависимостей.
Они "пинят", в Pipfile.lock. А коли же вы его потеряли — из Pipfile установятся последние версии пакетов, если вы не укажете другое сами. Это уже в ответ на:
лучше это делать явно, руками и поднимать версии на нужные, а не на самые последние
включать в тулзу, которая управляет пакетами, функционал чтения и активации файлов
Тут я и согласен, и нет. С одной стороны — вы правы, с другой — а зачем мне использовать какой-то дополнительный пакет, если это сделает pipenv? Он просто сделает внутри окружения доступным всё что есть в .env как переменные окружения. Это даже логично звучит. Pipenv все-таки и окружением управляет. Я скорее рад этому, чем нет.
Я допускаю, что не весь функционал Pipenv может быть нужен всем разработчикам, многие спокойно себе живут используя другие инструменты, но в мире Питона не было удобного способа делать свою разработку удобной, как это уже давно сделано в других "мирах" (PHP, JS, Ruby, ...). Использовать его или нет исключительно ваше право, но многие разработчики очень довольны, просто дайте ему шанс. Возможно, удасться насладиться тем, что за вас все сделали и вы можете просто заняться разработкой, а не играми с окружением и зависимостями! :)
Эту "штуку" Pipenv вполне себе поддерживает.
А еще много других, крутых фишек. Все в одном пакете, с удобным CLI.
Советую более детально ознакомиться на официальном сайте проекта.
Проект активно развивается, но я, например, пока не перешел на него. Производительность хромает (по крайней мере на Windows), некоторые решения разработчиков в дизайне инструмента сомнительны (в Issues много интересных обсуждений).
Присматриваюсь к poetry, попутно используя старый добрый pip + venv.
mypyпоможет уже начиная с момента, когда мы попытаемся передатьtimes: strаргуметом вrange(...), который ожидаетint.Но если говорить про момент с условием —
mypyсообщит, что тут что-то не так:Похоже, тут
mypyвидит, что одной и той же переменной передаютсяCallableс разными типами и он сразу же об этом сообщает.Так же, насколько я понял,
mypyделает предположение (так как он не может знать заранее что будет лежать вnewInterface), что условие выполнится и вsecretбудет лежать функцияgreet_times2, которая на вход принимаетstr, strи не поднимает дополнительную тревога .Если же присвоение функций в условии поменять местами (при выполнении условия в
secretприсвоитсяgreet_times, которыйstr, int),mypyдаст знать, что мы еще и типами ошиблись:В общем, штука мощная и прикольная. Неожиданно приятно, что малыми усилиями можно защитить себя от выстрелов в ногу даже в Питоне.
Вот пример, если я правильно понял ваш вопрос:
mypy app.pyнайдет и сообщит мне о двух ошибках: как для оригинальной функции, так и для делегированной:На самом деле, они мощные и умеют сильно больше, чем пример выше.
Даже если немного начать типизировать код — это помогает. Это еще называют gradual typing.
Может показаться, что «для этого нужно стороннее решение», но это не так важно, так как mypy — самый используемый тайпчекер, стандарт дефакто и поставляется с любым плагином для среды разработки по Питону (VSCode тот же). В PyCharm есть свой. То есть, проверка типов встраивается очень приятно и без лишних телодвижений.
Чем он вас цепляет после Питона?
Я хоть владею Питоном не профессионально, но даже учить Go и его особенности неприятно. Мне куда ближе тот же Kotlin.
Очень интересный "недостаток" в книге по Django 2.1, учитывая это:
Django 2.1 release notes
Django 2.0 release notes
Сейчас «Семейная подписка» работает.
Для ваших целей есть специальные файловые хостинги с документированными лимитами. :)
Если человек покупает Яндекс.Смарфтон, то очень странно от него ожидать, что он захочет удалить Яндекс.Браузер. Ты уже или весь в этой экосистеме или непонятно зачем покупал.
А оно есть.
Возможно, лимиты больше.
Интересно, а какое ограничение допустимо для шаринга файлов?
Или вы решили Яндекс.Диском раздавать файлы сотням / тысячам людей? Не для этого же функция создавалась.
Это очень интересное и спорное утверждение.
Вы когда ей пользовались последний раз? 2 года назад?
Если в код из примера после
{precision}добавитьf— получим 4 знака после запятой:Еще сейчас активно разрабатывается Vibora — асинхронный веб-фреймворк, внутренности которого написаны на Cython, из-за чего он получился невероятно быстрым (на странице проекта есть относительно свежие бенчмарки). До production-ready ему далеко, но «звездочку» им поставил, однозначно стоит следить. :)
pipenv install <package> --skip-lockТут явно делается обратное. Вы всегда хотите запинить версии. А если нет — пожалуйста, вот флаг.
Для установки пакетов НЕ нужно активировать окружение самому. Даже для запуска скриптов можно НЕ активировать окружение самому, а воспользоваться
pipenv run <command>, чтобы исполнить что-нибудь из нужного окружения.Так и запишем!
Еще раз.
pipenvпри желании расширяется возможностямиpyenv. Зачем себя ограничиватьpyenv, а остальные вещи делать руками или другими способами — непонятно.На любой "платформе"?
bash/zsh/cmd/powershell?Автоматическую активацию окружения уже давно можно сделать и просто в
pip, подключив нужный плагин в том жеzsh. Такие же штуки есть и дляpipenv.Никак, сори, я неправильно прочитал ваш комментарий. Я держал у себя в голове информацию об этом.
Нет
Pipfile.lock— всегда ставит последние версии пакетов, если не указано иначе.Не совсем понимаю, как тут будет мешать
pipenv. Есть проект на Python, в нем есть свой.env,pipenvего подтянул. Никто не мешает использовать остальные тулзы.Ну, это очевидно. Вы превращаете свой неудобный процесс разработки в удобный. :)
Ничего не теряется. Даже если вы будете собирать свое приложение в Докере — вам так или иначе нужны конкретные версии пакетов, которые будут лежать в
Pipfile.lock. А его уже разработчик будет создавать при помощиpipenvс великим удовольствием.Конечно, это невероятно упрощает работу. Раньше нужно было делать несколько вещей и следить за ними самому (где создавался
venv, активировал ли я его), а тут всё сделали за меня.Поставить инструмент хуже, чем инструмент лучше? Странное предложение. Тем более, что
pipenvумеет использоватьpyenv, поэтому минусов никаких на выходе не получаем.Нет, не избыточно. Это автоматизация рутинного процесса в инструменте, который я буду использовать каждый день. И другие разработчики тоже. А то все городят свой костыль.
А суть фичи не в этом, а в том, чтобы оповещать разработчика о версиях пакетов, которые известны наличием уязвимостей. Это круто. Лучше когда оно есть, чем когда нет, согласитесь.
Они "пинят", в
Pipfile.lock. А коли же вы его потеряли — изPipfileустановятся последние версии пакетов, если вы не укажете другое сами. Это уже в ответ на:Тут я и согласен, и нет. С одной стороны — вы правы, с другой — а зачем мне использовать какой-то дополнительный пакет, если это сделает
pipenv? Он просто сделает внутри окружения доступным всё что есть в.envкак переменные окружения. Это даже логично звучит.Pipenvвсе-таки и окружением управляет. Я скорее рад этому, чем нет.Я допускаю, что не весь функционал
Pipenvможет быть нужен всем разработчикам, многие спокойно себе живут используя другие инструменты, но в мире Питона не было удобного способа делать свою разработку удобной, как это уже давно сделано в других "мирах" (PHP, JS, Ruby, ...). Использовать его или нет исключительно ваше право, но многие разработчики очень довольны, просто дайте ему шанс. Возможно, удасться насладиться тем, что за вас все сделали и вы можете просто заняться разработкой, а не играми с окружением и зависимостями! :)Эту "штуку"
Pipenvвполне себе поддерживает.А еще много других, крутых фишек. Все в одном пакете, с удобным CLI.
Советую более детально ознакомиться на официальном сайте проекта.
Проект активно развивается, но я, например, пока не перешел на него. Производительность хромает (по крайней мере на Windows), некоторые решения разработчиков в дизайне инструмента сомнительны (в Issues много интересных обсуждений).
Присматриваюсь к
poetry, попутно используя старый добрыйpip+venv.