Комментарии 81
Новость одна из самых обсуждаемых тем на долинском хакер ньюс за сегодня.
Мне почему-то кажется, четвёртого Питона не будет никогда. "Нет повести печальнее на свете, чем о питонах — втором и третьем". Наступать на те же грабли заинтересованные люди вряд ли станут.
Понятно что тут слегка другая ситуация, но мне кажется, тоже найдутся люди, которые мечтают обо всем новом. И они даже вполне могут свое видение продавить временами.
Ага, а у некоторых сисадминов уже по пять-шесть вируталок с конкретными версиями жабы
Из-за Джавы? Или из-за конкретных классов кривых либ?
Мы пока на мэйвене были так 1000 разработчиков синхронизировали через одну и туже версию всего на проде!!! А кто не мог — убер джар или шейдинг.
Это некорректное сравнение.
Во-первых, исходные коды в Java практически идеально совместимы с более новыми версиями. С Питоном это нет так.
Во-вторых, в Java исходный код компилируется в промежуточный код (bytecode). И вот он в принципе совместим с более новыми версиями JVM. Как следствие, в одном процессе может быть исходный код от разных версий Java (или даже из разных языков программирования), да еще и скомпилированный под разный bytecode. И все будет корректно работать. А с Питоном такое не работает, так как исходный код должен быть совместим с конкретным рантаймом
В-третьих, в Java обратная совместимость в библиотеках на порядки лучше, чем в Питоне (особенно, между второй и третьей версиями). Нарваться на проблему при переходе на новую версию Java намного сложнее (хоть и возможно). Но это уже по моим наблюдениям, могу ошибаться.
Корректнее сравнивать Python и JavaScript, так как они оба интерпретируемые.
Далеко не всегда. Если бы это было так, то я лично (и по последним опросам — еще 20% пользователей) все еще не сидели бы на Java 8.
Я говорю про исходный код, а не про runtime. Про runtime — это пункты 2 и 3.
А на Java 8 зачастую сидят из-за древней библиотеки, до до обновления которой руки не дошли, так как сам сервис не приоритетный.
В случае с Питоном для миграции с 2 до 3 необходимо одновременно обновить практически весь исходный код, обновить практически все библиотеки, причем для того, чтобы хотя бы исходный код был бы совместим. А потом необходимо исправлять ошибки, связанные с обновлением API, так как некому подсказать на этапе компиляции, ввиду отсутствия этого самого этапа.
И из-за этого, для той же Java можно сравнительно легко мигрировать большие проекты, тогда как на Python проблемы с миграцией вылезут намного раньше, на более скромной кодовой базе.
Если просуммировать: да, и в Java, и в .Net тоже существуют проблемы обратной совместимости, просто их на порядок меньше.
Ну т.е. я говорю про возможности. Можно и версии выпускать более совместимые, и люди всегда находятся такие, кто и несовместимость готов терпеть, ради чего-то полезного. Как реально будет — мы не знаем, но варианты очевидно есть разные.
Разница в компилируемости. Если под Java написали библиотеку под Java 1.6, которая не хочет компилироваться под Java 17, и одновременно с этим разработчики не хотят обновлять её, то это не страшно, так как JVM выполняет bytecode. А в случае с Питоном это важно, так как весь исходный код программы и всех библиотек должен быть совместим с текущим рантаймом.
Вы в курсе, что есть скажем GraalVM реализация питона 3.8, которая компилирует в Java байткод? И JIT там из коробки есть. И рантайм там JVM. Может разница и есть, но эта задача совершенно не относится к нерешаемым.
Я не до конца понял аргумент, я думаю… Питон поставляется в виде исходных кодов. Для того, чтобы скомпилировать питон в машинный код, необходимы как минимум две вещи — исходные коды и интерпретатор/компилятор конкретно для этой версии исходников.
Если кто-то преобразовал питон в байткод, то этот человек неявно зашил версию компилятора для языка программирования. Это аналогично с тем, что вместе с исходными кодами сразу поставлять условный python.exe.
Основная сложность в том, что когда вы запускаете сервис, Вам необходимо распарсить исходные коды и вашего проекта, и всех библиотек. И делается это в последний момент, в уже самом рантайме. То есть не получится предкомпилировать библиотеку один раз, а потом поставлять именно "байткод".
То есть даже если GraalVM может преобразовать исходник на питоне в байткод, Вы не сможете распространять результат этого преобразования, так как это выход за экосистему Питона — никто не гарантирует совместимости и пр. И я даже не уверен, что GraalVM сможет гарантировать.
Кратко: для Java Вы сможете скомпилировать два модуля под разными версиями (1.6 и 17) и использовать их в одном процессе, даже если старый модуль не смог бы скомпилироваться 17й Джавой (ибо язык поменялся), а с Питоном так нельзя — версия компилятора (то есть читателя исходных кодов) должна быть одной на весь процесс.
Вы мне рассказываете, что сейчас в текущей экосистеме некоторые вещи нельзя. Но практика показывает, что можно сделать работающий питон в рамках экосистемы JVM (JYthon вообще много-много лет), или GraalVM, то есть довольно таки отличной от существующей. То что она «не такая» — не делает ее не пригодной для употребления.
Аналогично, совершенно условная четвертая версия питона вполне могла бы поменять экосистему и правила игры таким образом, чтобы получить какой-то профит, ради которого на нее перейдут многие. И этим многим при этом будет совершенно наплевать, что миграция стоит им усилий. Возможно она им и не будет ничего стоить — они просто начнут новый проект на этой версии. Что при этом будут делать остальные? А что делают сегодня те, кто остался на питоне 2? Ну вот примерно тоже самое и будут.
Понятно что заинтересованные люди будут избегать специального создания новых несовместимостей, но я тем не менее не вижу в этом сценарии ничего невозможного. Вопрос только в том, дает ли несовместимость какой-то профит, который перевешивает создаваемые ей проблемы.
П может и будет, но без таких огромных несовместимостей.
Сломают пару фич и все.
Кстати можно посчитать, что если бы интерпретатор Питона был в два раза быстрее, то можно было бы сократить расход электроэнергии и выбросы СО2 в атмосферу на чувствительную величину, это как с биткоином.
А что именно как с биткоином? Если скорость майнинга «ускорится» у всех в N раз, не изменится вообще ничего, кроме того что значение сложности станет в N раз больше.
Разве все майнят одним алгоритмом?
Мне кажется разными. И соответсвенно скорость изменится не у всех, а только у тех, кто найдёт более экологичный вариант. Что конечно не сократит выбросы, а может даже увеличить.
Разве все майнят одним алгоритмом?
Конечно, грубо говоря, какие есть варианты алгоритмов для расчета 1+1.
Вообще, одна компания запантентовала небольшой шорткат именно в майнинге биткойна. Там заметили, что префикс хеширемой строки не меняется, а значит часть работы не нужно повторно делать. Ускорение — 20-30%. Ну и патентом запретили другим использовать это.
+1↑1
Разумеется не обойдётся только «поиском» зловредного кода, его будут и удалять, сотрудники Гугл с помощью алгоритмов Гугл. Значит начнутся ситуации как с Google Play, «спасите мой пакет забанили без объяснения причин!»я конечно понимаю, что это чистый поток сознания, но мне интересно — каким образом изменения в pip забанят какие-то пакеты? Впишут в код pip «return True if packet.name == `packet_name`else False»?
Рад, что в его мире все так просто, че.
Ee Durbin директор Питона по инфраструктуре уже согласился.
Это очень хорошо, сказал он, потому что теперь можно использовать BigQuery на индексе репозитория!
Это же очень давно можно, и это большая проблема, потому что полные метаданные о пакетах в PyPI можно получить только через проприетарное гугловское API, требующее ещё и наличия Google аккаунта. Для Repology, например, мне пришлось написать сервис который собирает частичные метаданные из нескольких разнородных, полурабочих и частично deprecated API, вместо того чтобы просто скачать json, как это делается для других поддерживаемых коллекций модулей включая RubyGems, crates.io, CPAN, CRAN, MELPA, Hackage, LuaRocks и т.д.
Что в этом плохого?
Никто не переживает за техническую часть. Все переживают о том, что как только Гугл захватит репозиторий, он начнет диктовать кому там можно быть, а кому нельзя. Например, есть кучу питон-скриптов по выкачиванию контента с разной степень платности и легальности. Их могут грохнуть на том основании, что они нарушают чьи-то там права.
Ee Durbin директор Питона по инфраструктуре уже согласился. Это очень хорошо, сказал он, потому что теперь можно использовать BigQuery на индексе репозитория!
Читаем тут: https://pypistats.org/about
Goal
PyPI Stats aims to provide aggregate download information on python packages available from the Python Package Index in lieu of having to execute queries against raw download records in Google BigQuery.
Data
Download stats are sourced from the Python Software Foundation's publicly available download stats on Google BigQuery. All aggregate download stats ignore known PyPI mirrors (such as bandersnatch) unless noted otherwise.
Так что он имел в виду под "теперь можно использовать BigQuery"? И когда они уже наконец сделают нормальное управление метаданными и прикрутят статистику к официальному PyPI?
Google объявили себя идейным спонсором Питона. Visionary Sponsor как они это называют. Начали они с того, что вчера перечислили в фонд Питона 350 тысяч долларов.
Перечислили деньги эквивалентные годовой заплате одного своего синьор-инженера. (пруф: https://www.levels.fyi/company/Google/salaries/Software-Engineer/L5/ ) Какой-то не тот смысл они вкладывают в слово "идейный"
Форк Питона не намного проще чем форк браузера, начнутся несовместимости, резкие изменения, могут выйти два совершенно непохожих друг на друга четвёртых Питона.
а необходимость создания отдельного «свободного от правил корпораций» registry (хранилища пакетов).
Ничего не мешает в любом (? вроде бы) языке программирования использовать пакет, который вы храните в исходниках, берете с гита/github/gitlab да или просто храните на своем корпоративном Nexus/ином хранилище.
С точки зрения борьбы с уязвимостями кода в экосистеме Python не хватает как минимум механизма аудита уязвимостей «из коробки» (например как npm audit), так что, кажется, положительных сторон все же больше.
каждый может модифицировать питон под себя
С двуединством Python 2+3 никак не могут справиться; а вы хотите, чтобы в ходу были 100500 слегка различающихся диалектов?
Лучше бы вложились в PyPy. У него гораздо больше перспектив. В том числе по скорости.
PyPy всё-таки слишком… мнэээ… своеобразная штука тем, что JIT у него не на целевой код, а на собственный интерпретатор, исполняющий этот код (!) Если целевой код более-менее однородный, это даст заметную прибавку, иначе — нет, но в любом случае это сильно хуже нормальной компиляции и в принципе не сможет достичь того же, что оптимизация под скорость целевого кода.
На нашем профиле задач (SIP плюс внутренний весьма развесистый текстовый процессинг) получается ускорение в 3-4 раза по сравнению с CPython. В то время как тупейший перевод на Java даёт ещё 2 раза по сравнению с PyPy, а умный — в 10 раз… с C++ я вообще боюсь сравнивать ;\
Вероятно, Unladen Swallow должен был перенести наработки V8 на Python, но его забросили (не в пользу Go ли?) Вот через 10 лет спохватились?
И на нем питон 4 уже не нужен, тк каждый может модифицировать питон под себя.
Только 1) уровень переработки интерпретатора должен быть очень высокий, 2) а нафига свой язык? чтобы не иметь возможности использовать готовый чужой код?
Что говорит, что подход верный
Насколько верный? Что он вообще помогает — факт, но что, если его запросто перебьёт реализация, которая хоть как-то оптимизирует исполнение собственно целевого кода?
но требует ресурсов для эффективного исполнения.
Каких именно ресурсов?
Базовая джава и есть именно такой оптимизаций.
Грааль доказывает эффективность подхода PyPy не потому что просто существует.
Вы можете чем-то подтвердить это своё утверждение? Доступные в Сети материалы прямо говорят, что GraalVM делает JIT (и особенно AOT) для целевого кода, а не кода собственного промежуточного интерпретатора.
Время и специалисты. Поддержка ентерпрайза, а не только научного общества. Ну или, как принято считать, деньги.
Как говорят, это можно было сказать честнее — "всё это пока полностью экспериментально". Но с учётом первого абзаца я вообще не понимаю, чи стоит обсуждать GraalVM в данном контексте.
Google захватывает Python