Как стать автором
Обновить

Комментарии 81

НЛО прилетело и опубликовало эту надпись здесь

Новость одна из самых обсуждаемых тем на долинском хакер ньюс за сегодня.

В статье большие проблемы с пунктуацией: не хватает запятых во многих местах. И в целом выглядит как поток сознания.

Мне почему-то кажется, четвёртого Питона не будет никогда. "Нет повести печальнее на свете, чем о питонах — втором и третьем". Наступать на те же грабли заинтересованные люди вряд ли станут.

Oracle же выпускает нынче Java раз в полгода. И тоже есть разные точки зрения, хорошо ли это или не очень. Но факт, что тоже есть люди и компании, которым такое положение вещей нравится. Они ставят новые версии раз в полгода, и им хочется иметь новые плюшки (ну и грабли, не без этого конечно) самыми первыми.

Понятно что тут слегка другая ситуация, но мне кажется, тоже найдутся люди, которые мечтают обо всем новом. И они даже вполне могут свое видение продавить временами.
Ага, а у некоторых сисадминов уже по пять-шесть вируталок с конкретными версиями жабы, ибо что-то работает нормально только с конкретными версиями.
Докер разве не решает такие проблемы?
Ни разу, т.к. часть этого барахла ещё и Windows+IE only
Ага, а у некоторых сисадминов уже по пять-шесть вируталок с конкретными версиями жабы
Из-за Джавы? Или из-за конкретных классов кривых либ?
Мы пока на мэйвене были так 1000 разработчиков синхронизировали через одну и туже версию всего на проде!!! А кто не мог — убер джар или шейдинг.
А черт его знает, вот железка стоит, вот у неё софт для управления. А работает он нормально только на какой-то определённой версии жабы. Или вот у той железки интерфейс управления — вебстраничка с java апплетами (превед древность, расчехляю IE 6.0 c JRE 1.5). И эта [censored] творится уже давно и со всеми. Juniper ещё недавно поставляли железо, где интерфейс управления был написан… на Adobe Flash. И в результате у сисадмина торчит парк виртуалок с парком версий жаб и, с 21 года, одной виртуалкой с flash-ем.
При этом совместимость у версия Java, даже если через 2-3, гораздо выше, чем между питон2 и питон3.
Ну, не везде. Скажем прямо, в 9 это сломали знатно. Но в целом — можно же делать и не ломая. Если с умом.
Ну, на самом деле такого было много — тут спасибо надо сказать проекту jigsaw. maven например сломали. И gradle заодно. Не говоря уже про более крупные вещи типа хадупа, у команд которых ушли годы на то, чтобы добиться совместимости. Это не значит, что сломали всех — просто в тот раз это было более массово.
Ну так починили же.
А питон совместимым и не будет
Починили. Местами — года через три, местами даже дольше.

Это некорректное сравнение.


Во-первых, исходные коды в Java практически идеально совместимы с более новыми версиями. С Питоном это нет так.
Во-вторых, в Java исходный код компилируется в промежуточный код (bytecode). И вот он в принципе совместим с более новыми версиями JVM. Как следствие, в одном процессе может быть исходный код от разных версий Java (или даже из разных языков программирования), да еще и скомпилированный под разный bytecode. И все будет корректно работать. А с Питоном такое не работает, так как исходный код должен быть совместим с конкретным рантаймом
В-третьих, в Java обратная совместимость в библиотеках на порядки лучше, чем в Питоне (особенно, между второй и третьей версиями). Нарваться на проблему при переходе на новую версию Java намного сложнее (хоть и возможно). Но это уже по моим наблюдениям, могу ошибаться.


Корректнее сравнивать Python и JavaScript, так как они оба интерпретируемые.

>Во-первых, исходные коды в Java практически идеально совместимы с более новыми версиями.
Далеко не всегда. Если бы это было так, то я лично (и по последним опросам — еще 20% пользователей) все еще не сидели бы на Java 8.

Я говорю про исходный код, а не про runtime. Про runtime — это пункты 2 и 3.


А на Java 8 зачастую сидят из-за древней библиотеки, до до обновления которой руки не дошли, так как сам сервис не приоритетный.


В случае с Питоном для миграции с 2 до 3 необходимо одновременно обновить практически весь исходный код, обновить практически все библиотеки, причем для того, чтобы хотя бы исходный код был бы совместим. А потом необходимо исправлять ошибки, связанные с обновлением API, так как некому подсказать на этапе компиляции, ввиду отсутствия этого самого этапа.


И из-за этого, для той же Java можно сравнительно легко мигрировать большие проекты, тогда как на Python проблемы с миграцией вылезут намного раньше, на более скромной кодовой базе.


Если просуммировать: да, и в Java, и в .Net тоже существуют проблемы обратной совместимости, просто их на порядок меньше.

Да это все вообще немного про другое. Я говорю о том, что вот есть пользователи Java — и среди них тоже имеются такие, что охотно мигрирует на каждую новую версию раз в полгода, а есть наоборот — те, кто сидят на старой версии 2014 года до последнего. И почему вы думаете, что а) среди любителей питона не найдется такой группы, как первая б) все другие версии питона будут делаться таким же несовместимыми, как питон 2 и 3?

Ну т.е. я говорю про возможности. Можно и версии выпускать более совместимые, и люди всегда находятся такие, кто и несовместимость готов терпеть, ради чего-то полезного. Как реально будет — мы не знаем, но варианты очевидно есть разные.

Разница в компилируемости. Если под Java написали библиотеку под Java 1.6, которая не хочет компилироваться под Java 17, и одновременно с этим разработчики не хотят обновлять её, то это не страшно, так как JVM выполняет bytecode. А в случае с Питоном это важно, так как весь исходный код программы и всех библиотек должен быть совместим с текущим рантаймом.

>это не страшно, так как JVM выполняет bytecode
Вы в курсе, что есть скажем GraalVM реализация питона 3.8, которая компилирует в Java байткод? И JIT там из коробки есть. И рантайм там JVM. Может разница и есть, но эта задача совершенно не относится к нерешаемым.

Я не до конца понял аргумент, я думаю… Питон поставляется в виде исходных кодов. Для того, чтобы скомпилировать питон в машинный код, необходимы как минимум две вещи — исходные коды и интерпретатор/компилятор конкретно для этой версии исходников.


Если кто-то преобразовал питон в байткод, то этот человек неявно зашил версию компилятора для языка программирования. Это аналогично с тем, что вместе с исходными кодами сразу поставлять условный python.exe.


Основная сложность в том, что когда вы запускаете сервис, Вам необходимо распарсить исходные коды и вашего проекта, и всех библиотек. И делается это в последний момент, в уже самом рантайме. То есть не получится предкомпилировать библиотеку один раз, а потом поставлять именно "байткод".


То есть даже если GraalVM может преобразовать исходник на питоне в байткод, Вы не сможете распространять результат этого преобразования, так как это выход за экосистему Питона — никто не гарантирует совместимости и пр. И я даже не уверен, что GraalVM сможет гарантировать.


Кратко: для Java Вы сможете скомпилировать два модуля под разными версиями (1.6 и 17) и использовать их в одном процессе, даже если старый модуль не смог бы скомпилироваться 17й Джавой (ибо язык поменялся), а с Питоном так нельзя — версия компилятора (то есть читателя исходных кодов) должна быть одной на весь процесс.

Давайте еще раз — я говорю о возможностях. Мы же вообще тут про возможность 4 версии питона обсуждали, если на то пошло.

Вы мне рассказываете, что сейчас в текущей экосистеме некоторые вещи нельзя. Но практика показывает, что можно сделать работающий питон в рамках экосистемы JVM (JYthon вообще много-много лет), или GraalVM, то есть довольно таки отличной от существующей. То что она «не такая» — не делает ее не пригодной для употребления.

Аналогично, совершенно условная четвертая версия питона вполне могла бы поменять экосистему и правила игры таким образом, чтобы получить какой-то профит, ради которого на нее перейдут многие. И этим многим при этом будет совершенно наплевать, что миграция стоит им усилий. Возможно она им и не будет ничего стоить — они просто начнут новый проект на этой версии. Что при этом будут делать остальные? А что делают сегодня те, кто остался на питоне 2? Ну вот примерно тоже самое и будут.

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

П может и будет, но без таких огромных несовместимостей.
Сломают пару фич и все.

Кстати можно посчитать, что если бы интерпретатор Питона был в два раза быстрее, то можно было бы сократить расход электроэнергии и выбросы СО2 в атмосферу на чувствительную величину, это как с биткоином.

А что именно как с биткоином? Если скорость майнинга «ускорится» у всех в N раз, не изменится вообще ничего, кроме того что значение сложности станет в N раз больше.

Разве все майнят одним алгоритмом?
Мне кажется разными. И соответсвенно скорость изменится не у всех, а только у тех, кто найдёт более экологичный вариант. Что конечно не сократит выбросы, а может даже увеличить.

Разве все майнят одним алгоритмом?

Конечно, грубо говоря, какие есть варианты алгоритмов для расчета 1+1.
Алгоритм может и один, имплементации разные. Расчет 1+1 на БЭСМ и на ARM прилично отличаются по энергоемкости.
Ну как-то разное железо это все таки не о алгоритмах разговор, а о железе непосредственно.

Вообще, одна компания запантентовала небольшой шорткат именно в майнинге биткойна. Там заметили, что префикс хеширемой строки не меняется, а значит часть работы не нужно повторно делать. Ускорение — 20-30%. Ну и патентом запретили другим использовать это.

машина может не поддерживать хранение переменной со значением 1, но может например хранить 7 и 13 и тогда эквивалент будет 1+1=7+7+7+7+(-13)+(-13)

+1↑1

Разумеется не обойдётся только «поиском» зловредного кода, его будут и удалять, сотрудники Гугл с помощью алгоритмов Гугл. Значит начнутся ситуации как с Google Play, «спасите мой пакет забанили без объяснения причин!»
я конечно понимаю, что это чистый поток сознания, но мне интересно — каким образом изменения в pip забанят какие-то пакеты? Впишут в код pip «return True if packet.name == `packet_name`else False»?

Удалят с pypi?

Так речь о том, что они будут модерацию репозитория пакетов производить, выискивая там пакеты со зловредным кодом, а не код самого пакетного менеджера править.
НЛО прилетело и опубликовало эту надпись здесь
Ну да, такую же модерацию как в golang — тотально отсутствующую.
НЛО прилетело и опубликовало эту надпись здесь

Кто пропускает-то? Автор опытный, премодерации нет.
Вы вот не пропустили, заглянули.
И я.

НЛО прилетело и опубликовало эту надпись здесь
Если бы Гугл не вел себя паскудно по отношению к разработчикам, не пришлось бы оправдываться. Дело-то хорошее, такое же объявление от Mozilla или Apache Software Foundation встретили бы исключительно позитивно. Репутация штука обоюдоострая.
Ага, и «Visionary» PSF им само приписало, по добрате душевной.
Отбросив конспирологию можно догадаться, что вслед за pip, следующим будет npm резопоторий? Ведь модерация в самом деле отсутствует, тому пример typesquoting и недавний necro-poisoning: medium.com/@alex.birsan/dependency-confusion-4a5d60fec610

Завис над термином typesquoting (цитирование типов??). Пришлось сходить по ссылке, чтобы понять, что вы хотели сказать. А всё потому, что typosquatting != typesquoting. Но по ссылке было всё равно интересно сходить.

Рад, что в его мире все так просто, че.

Статья — машинный перевод? О чем это предложение?
Ee Durbin директор Питона по инфраструктуре уже согласился.
Это очень хорошо, сказал он, потому что теперь можно использовать BigQuery на индексе репозитория!

Это же очень давно можно, и это большая проблема, потому что полные метаданные о пакетах в PyPI можно получить только через проприетарное гугловское API, требующее ещё и наличия Google аккаунта. Для Repology, например, мне пришлось написать сервис который собирает частичные метаданные из нескольких разнородных, полурабочих и частично deprecated API, вместо того чтобы просто скачать json, как это делается для других поддерживаемых коллекций модулей включая RubyGems, crates.io, CPAN, CRAN, MELPA, Hackage, LuaRocks и т.д.

Если они сделают аналог V8 для Python… CPython, PyPy — почему не быть GPython?
Что в этом плохого?

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

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/ ) Какой-то не тот смысл они вкладывают в слово "идейный"

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

а необходимость создания отдельного «свободного от правил корпораций» registry (хранилища пакетов).

Ничего не мешает в любом (? вроде бы) языке программирования использовать пакет, который вы храните в исходниках, берете с гита/github/gitlab да или просто храните на своем корпоративном Nexus/ином хранилище.

С точки зрения борьбы с уязвимостями кода в экосистеме Python не хватает как минимум механизма аудита уязвимостей «из коробки» (например как npm audit), так что, кажется, положительных сторон все же больше.
НЛО прилетело и опубликовало эту надпись здесь

Да, GitHub для open source тоже быть бесплатным не может. (Irony)


Многие сервисы (CICD, Git Servers, Sec Scanners) бесплатны для open source, и получают прибыль за счёт корпоративных клиентов, которые платят за дополнительные фишки и за приватность (исходников).

НЛО прилетело и опубликовало эту надпись здесь

А мне думается, что в нынешнем виде github это достаточно мощный инструмент для контроля над рынком OpenSource. Плюс аналитика там, хантинг. И, конечно же, энтерпрайз-левел фичи.

НЛО прилетело и опубликовало эту надпись здесь
каждый может модифицировать питон под себя

С двуединством Python 2+3 никак не могут справиться; а вы хотите, чтобы в ходу были 100500 слегка различающихся диалектов?
НЛО прилетело и опубликовало эту надпись здесь
PyPy вроде полностью поддерживает 3й питон. Просто по минорным версиям отстаёт.
НЛО прилетело и опубликовало эту надпись здесь
Лучше бы вложились в 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 в данном контексте.

НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Думаю, ничего плохого в форках Python, если таковые произойдут, нет. Конкуренция всегда на пользу. И как сожительствует семейство языков C, к которому уже все привыкли и которое никому не мешает, так и Python будет.
НЛО прилетело и опубликовало эту надпись здесь
«Не можем побилдить прод, пока не подключатся сиды»?
Серверных сидов будет много и они всегда будут доступны, ими станут обычные сервера с зеркалами.
Так что вижу тут вполне развитие событий. Вопрос встанет только с тем, что трекер должен быть один, а это централизация в торрентах.
Очень пугающая новость. Боюсь, что если гугл захватит власть над питоном, то сможет навредить сообществу огромным количеством способов, которые мы пока даже представить себе не можем. Получим второй rust без нормальной спецификации и с компилятором, компилирующимся только его же бинарником строго той же версии. Или вот GPL создавался вроде как для того, чтобы нельзя было так просто вредить пользователям. И что? Гугл сожрал и не подавился, выдав хром и андроид, дающие гуглу огромную власть.
Не удалось прочитать статью до конца из-за азапитоза текста в почти терминальной стадии. Поэтому вот, пользуйтесь, не стесняйтесь.
image
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории