зачем это не нужно?

ну я так понял, шо аннотации очень помогают для отладки кода, да и вообще удобно же для всяких ide. например:

my_var: str = input("Ну-ка сюда че напиши?")

# и вот здесь уже ide уже предпологает что он ожидает,
# и сразу же автодополняет строковые методы
print(my_var.uppercase())

меня в первую очередь волнует производительность кода, насколько он будет нагружать процессор или ram компьютера? ты пробовал вообще играть с этими аннотациями?

непонятно, с чего бы? интерпретатор их игнорирует

Использование скриптоты отрицательно сказывается на времени запуска программ.

Аннотированием по сравнению с этим можно пренебречь.

это нужно только для линтеров, интерпретатору на них пофиг

анонимное комментирование отрицательно сказывается на уровне троллинга

annotating source code had adverse effects on startup time of Python programs.

источник

У тебя есть какое-то опровержение тому факту, что итерпретатор питота стартует кардинально медленнее хелловорлдного бинаря?

А так я к тому, что оп заморачивается чушью.

да, но не нет. интерпритатор то их игнорирует, но при «компиляции» в байткод они парсятся а также происходит валидация доступности заданных типов в скопе на этапе построения ast (и в случае чего будет выдана ошибка).

ну ок. а если программа уже скомпилирована в байткод и лежит в кеше, аннотации как то влияют?

ну дык замерь, че.
насколько помню, импакт заметен только на больших файлах с кучей аннотаций - если разбито на небольшие модули, то пофиг.
хотя если используется новый режим парсинга аннтоаций из 3.7, то там думаю все иначе

вот тогда нет.

но это опять таки про «старый» режим аннотаций.

Использование скриптоты отрицательно сказывается на времени запуска программ.

Когда-то давно делал замеры времени запуска скриптов, выводящих просто строку «hello». Питон стартует (скрипт отрабатывает) примерно 500-1000 раз медленнее bash и perl. Bash на 10% быстрее perl. Кстати, python2 стартует быстрее чем python3, но долгий и сложный скрипт на python3 отрабатывает быстрее чем python2 (скрипт один и тот же).

Чё-то не то ты мерил. Баш быстро стартует скрипты потому, что он уже в памяти, твой шелл. А питон стартует относительно медленно первый раз, потом также как и баш, но сам питон быстрее баша в несколько раз. Быстрее питона стартует и работает тока node.js и go, про сишку не говорю даже. В плане написания какой-либо бизнес логики для быстрого старта go идеален. Насчёт пёрла - он уже не нужен, не юзабелен.

Да всё равно, можно повторить эксперимент с даш или чем-нибудь ещё. Баш конечно долго стартует, но зш (особенно с плагинами) ещё дольше, а питон запускается под 10 секунд (и да он уже вроде висит в памяти у какой-то программы и запускался перед этим). Разница будет только если его запускать подряд много раз, тогда огромная задержка лишь у первого запуска. Как по мне это огромный недостаток, особенно если посмотреть на си, которая динамически линкуется с полсотней либ и отрабатывает за какие-то наносекунды. И кроме того, большинство задач, где применим шелл, завершаются до того как питон только запустися и прочитает все свои файлы, вот это тоже проблема.

Сказывается отрицательно, но когда запускается готовый байт код, то разницы нет.

Чё-то не то ты мерил.

Сам измерь. К такому измерению подтолкнули тормоза при при отработке ./configure со своим враппером над компилятором. С враппером на питоне практически невозможно было дождаться ./configure. Результат измерения показал, что причина в долгом страте python. Враппер был переписан на перле из-за ущербности bash по сравнению с perl.

Да не. У меня джанга с кучей модулей стартует 0.5 сек на hdd и готова к отдаче запросов, на ssd 0.1. Что там за configure хз, видимо, внешние процессы стартовала.

Пишу код прямо здесь, возможно, есть ошибки

hello.py

#!/usr/bin/python
print("hello")

hello.pl

#!/usr/bin/perl
print "hello\n"

$ time for i in {1..1000}; do ./hello.pl; done
$ time for i in {1..1000}; do ./hello.py; done

В груви тоже проблема была с указанием типов: когда они указывались, интерпретатор делал дополнительные проверки и исполнение кода замедлялось.

Пиши самодокументируемый код.

Конечно сказывается.

Так себе помогают, mypy довольно тупой, но это действительно лучше чем ничего. А вот IDE умнеет на глазах, во всю использую типизацию именно ради этого. Но вообще, я бы лучше этого не делал, ибо смысла никакого.

В питоне аннотации ни на что не влияют, издержки есть только при парсинге.

Аннотирование исходного кода отрицательно сказывается на времени запуска программ на Python?

Так-то конечно да, поскольку нужно как минимум импортировать typing, как максимум - импортировать всё то что раньше можно было протащить через свои классы и модули как «неизвестно что». Плюс какой-то оверхед на парсинг. Но на своём коде (10k sloc) я разницы не заметил. В рантайме оверхеда в любом случае никакого нет.

И вообще стоит ли писать весь код аннотируя везде? Вы как относитесь к аннотациям в Python?

Абсолютно стоит, так питон становится наконец похож на язык программирования. Упрощает рефакторинг и спасло уже от кучи проблем в рантайме. Если нет достаточного покрытия тестами, незаменимо, а просто полезно вообще всегда.

Чтобы сбросить страничный кэш, dentry и inodes:

echo 3 > /proc/sys/vm/drop_caches

perl --version

This is perl 5, version 30, subversion 0 (v5.30.0) built for x86_64-linux-thread-multi

python -V
Python 3.7.3

pypy -V
Python 2.7.13 (8cdda8b8cdb8ff29d9e620cccd6c5edd2f2a23ec, Apr 23 2019, 17:07:51)
[PyPy 7.1.1 with GCC 8.3.0]

CPython

time python -c 'print("Hello World")'
Hello World

real    0m0.740s
user    0m0.028s
sys     0m0.008s

Второй запуск:

time python -c 'print("Hello World")'
Hello World

real    0m0.055s
user    0m0.012s
sys     0m0.013s

PyPy

time pypy -c 'print("Hello World")'
Hello World

real    0m0.754s
user    0m0.040s
sys     0m0.040s

Второй запуск:

time pypy -c 'print("Hello World")'
Hello World

real    0m0.120s
user    0m0.066s
sys     0m0.020s

Perl 5

time perl -e 'print "hello\n"'
hello

real    0m0.446s
user    0m0.000s
sys     0m0.010s

Второй запуск:

time perl -e 'print "hello\n"'
hello

real    0m0.004s
user    0m0.000s
sys     0m0.004s

time for i in {1..1000}; do luajit -e 'io.write("Hello World!\n")'; done

если ты хочешь позадротить с вводом выводом в bash pipe

5-звездочный, замеряющий время одиночного запуска, и зачем-то дропающий кеш. Откуда беруться такие?

А чего это ты так занервничал? Типа слился шоли?

А питон стартует относительно медленно первый раз

А только первый раз обычно и нужен. Мне тут приходится на перле писать когда время запуска критично. Перл еще и заметно быстрее на строках и регулярках к тому же.

И что можно увидеть в твоих числах? Что одно и то же измерение покажет результат различающийся в 1000 раз? Что в резултате только одна значимая цифра, что следующая цифра сможет поменять результат на 25%? Статистические выбросы? Что в семье не без урода?

Я тебе показал как примерно составить эксперимент: отдельный исполняемый скрипт, который дергается (статистически) заничимое количество раз.

А ещё длинные названия переменных замедляют, т.к. файл с диска надо читать, но это не повод писать говнокод и заниматься преждевременными оптимизациями на спичках. Вот когда программа работает и тормозит, тогда стоит задуматься почему и что с этим делать.

А ещё длинные названия переменных замедляют, т.к

Вот кстати да, поэтому Java так и тормозит!

А теперь оберни «hello world» в переменную из одной буквы и из 20. И проверь.

Java - байткод. Там внутри нет длинных переменных )

Да да, и не тормозит она)) Вот в ассемблере все коротко:

mov ax,5

Пообколются своей утиной типизацией, а потом в аннотации долбятся.