Мэйнтейнер системы управления версиями Mercurial подвёл итог работы по переводу проекта с Python 2 на Python 3. Несмотря не то, что портирование началось ещё в 2008 году и было форсировано в 2015 году, полноценная возможность использования Python 3 была реализована только в последней ветке Mercurial 5.2...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=52184
Хм. Тут, скорее, вопрос о качестве кодовой базы Mercurial
Ну то есть вы, как специалист по кодовой базе Mercurial, имеющий многолетний опыт поддержки крупных проектов, сейчас приложите разумное проверяемое обоснование наличия лучшего решения, правильно?
> так как тесты не охватывают 100% кодовой базы, а многие проблемы незаметны при статическом анализе и проявляются только во время выполненияВроде сами признали, по тексту новости сложилось такое впечатление. Может вы что-то знаете чего не знаем мы?
Механический подсчет покрытия тоже не гарантирует ничего.Вот, допустим, есть такая функция:
int f(int x, int y) {
int arr[2] = { 0, 0 };
int i = 1;if (x == 1)
i--;if (y == 1)
i--;return arr[i];
}Сделали тесты на f(0, 1) и на f(1, 0), test coverage бодро рапортует 100%, а программа падает.
Удваиваю. Покрытие ради покрытия ещё ни о чём не говорит
Особенно грустно, когда тестами покрывается реализация, а не интерфейс (API, а не графический) -- рефакторинг превращается борьбу со сломанными тестами. В результате тесты перестают помогать разработке и вместо этого сковывают -- каждое движение заставляет сделать ещё 100500 правок. Интересно при этом то, что прохождение 100% тестов не гарантирует отсутствие ошибок
Покрывать тестами надо и то, и другое.
Юнит-тесты хороши для библиотек, реализующих нетривиальные алгоритмы, особенно оптимизированные, когда логику уже не так-то просто проследить. Во время написания алгоритма обычно помнишь о хитрых edge cases, которые надо проверить, а при внесении изменений через несколько лет можно и не вспомнить, особенно если изменения вносит кто-то другой.
Покрывать же юнит-тестами всякую там обвязку - во-первых, сложно, а во-вторых, бессмысленно: обвязка обычно не имеет самостоятельной ценности, а важна вкупе с использующим ее кодом, который может так же легко измениться, и получится бессмысленная работа по поддержанию тестов ради тестов. Важна работа предоставляемого API - и его-то тут и надо тестировать.
В качестве ответа я сошлюсь на Линуса. "Не ломать юзерленд" -- это значит не менять внешние API ядра.
При этом, внутренние API (что есть реализация) могут запросто меняться. По этой причине ядерные блобы в линуксах -- дурной тон.
А тут я полностью согласен. Но тестами на API сложно покрыть edge cases в алгоритмах (конечному пользователю пофиг, какие там внутри алгоритмы) - потому нужны оба.
> А тут я полностью согласен. Но тестами на API сложно покрыть edge cases в алгоритмах (конечному пользователю пофиг, какие там внутри алгоритмы) - потому нужны оба.Очень вероятно, что мы называем одни и те же вещи разными словами. Тест внешнего API включает в себя и проверку результата. Сам алгоритм алгоритму рознь: для чистых функций мы имеем право применять lru_cache, что формально меняет алгоритм. Иногда ради производительности можно пойти на коренные изменения алгоритма: https://ru.wikipedia.org/wiki/%D0%91%D1%...
Наконец, реструктуризация меняет алгоритм, но не должна менять результат
Тут ещё вопрос, где API. Например, в Solaris был баг в реализации qsort(), который приводил к тому, что для входных массивов с пачкой идущих подряд одинаковых значений сортировка занимала неприлично долгое время. Да, конечно, в quicksort amortized n log n, и worst case n^2, но разница с реализацией из BSD или Linux была на порядок.В случае с Solaris libc, qsort() - это вроде как API. А если кто-то скопипастил эту же реализацию в свой проект, и использует для сортировки во внутренней реализации - там вроде как юнит-тест нужен, ведь подготовить такой тестовый набор данных "снаружи", на котором эта проблема проявится, может оказаться крайне сложно. Но покрыть тестом один фиг надо.
Принято. Речь о тонкой границе, когда компонент реализации стабилизируется и становится внутренним API -- на него завязываются другие внутренние компоненты приложения.
ИМХО тут важно соблюсти баланс -- если от компонента что-то зависит, должны быть тесты, однако эти же тесты не должны связывать руки, если компонент необходимо подвергнуть модификации. Где именно этот баланс -- я не знаю.
Вероятно, вы говорите о разных вещах одними словами. И для этих разных вещей придумали разные слова: функциональное и юнит-тестирование.
Спасибо. Учту
Так вы, это, мутируйте поменьше, и никто никуда падать не будет.
Это тоже ничего не гарантирует. Точно такую же проблему можно показать и на чистых функциях с рекурсией.
> Так вы, это, мутируйте поменьше, и никто никуда падать не будет.Иммутабельность не является гарантией отсутствия ошибок. Иммутабельность не гарантирует отсутствие падений.
Всему своё время и место, включая мутабельность и иммутабельность
> Ну то есть вы, как специалист по кодовой базе Mercurial, имеющий многолетний
> опыт поддержки крупных проектов, сейчас приложите разумное проверяемое обоснование наличия
> лучшего решения, правильно?Вчитайтесь в комментарии этого персонажа: оно же пишет хвостом вебню. Естественно, хвостатые любят взрывные инновации прогресса, обмазываться свежатиной и Пихтон.
Если я не люблю сeкс с трyпами — я тоже «хвостатый»?
> Если я не люблю сeкс с трyпами — я тоже «хвостатый»?Если в контексте обсуждения языков программирования у тебя возникают подобные мысли, тебе _необходимо_ посетить психиатра.
В контексте обсуждения судьбы Mercurial.
У него весьма очевидная судьба: будет зохаван гитом.
Зато как раз их сейчас гит от нормальных прогеров окончательно втрамбует в грунт - у него нет этих вебмакакопроблем :)
> Ну то есть вы, как специалист по кодовой базе Mercurial, имеющий многолетний опыт поддержки крупных проектов, сейчас приложите разумное проверяемое обоснование наличия лучшего решения, правильно?Ситуация настолько очевидна, что наилучшее решение может огласить любой не-специалист: прекратить надругательство над Mercurial.
He's dead, Jim.
Да тут к гадалке не ходи...Ну подумайте хоть немного: переход на Python3 давно сделало большинство крупных проектов. Чуть менее чем все, например, среди околонаучных и DS приложений питона. Причем какая-нибудь pandas по объему кода вполне сравнима с сабж.
И, как правило, умудрялись это делать без необходимости поддерживать отдельные кодовые базы для 2 и 3.
Справедливости ради, у них не было стапятисот ваcянских плагинов, с которыми надо было поддерживать совместимость.
Вы знаете, тут все не так однозначно. АПИ плагинам же не феи-валшебницы нарисовали.
Зашёл на сайт какой-нибудь pandas. Нажал «get pandas», «download». Получил 404.Знаете, я лично как-то рад, что эти ребята не занимаются разработкой одной из систем управления версиями файлов, которой я пользуюсь.
> Зашёл на сайт какой-нибудь pandas. Нажал «get pandas», «download». Получил 404.И рассказал об этом на opennet, а не мейнтейнерам :)
Честно говоря, мне бы в голову не пришло воспользоваться этой кнопкой -- пакеты ставятся через pip. Может, вы и deb/rpm/whatever-пакеты так в свою систему ставите? Пилите кулстори, как вы добрались до этой кнопки, уж очень любопытноА вообще аргументация просто чумовая:
1) Найти баг в функционале, который использовался в последний раз лет дцать назад
> 2) Знаете, я лично как-то рад, что эти ребята не занимаются разработкой одной из систем управления версиями файлов, которой я пользуюсь.
3) PROFIT
UPD: ситуация ещё смешнее! Пока что не работает только 1 ссылка -- на релиз 1.0.0. И я понимаю, почему ребята не торопятся -- на pypi в целях безопасности запрещено обновлять пакет без изменения версии. Я уже несколько раз обнаруживал баги в собственных пакетах спустя часы после релиза -- приходилось выкатывать следующий релиз.
Короче, потерпите
> И рассказал об этом на opennet, а не мейнтейнерам :)Я рассказал об этом человеку, который первый заговорил о pandas как о примере качественного крупного проекта, успешно мигрировавшего на Python 3. Что я написал (или прямо сейчас пишу, или буду писать) и кому в проекте pandas — вы не знаете, но мнение уже заранее имеете. Поздравляю, вы обделались.
> Честно говоря, мне бы в голову не пришло воспользоваться этой кнопкой -- пакеты ставятся через pip. Может, вы и deb/rpm/whatever-пакеты так в свою систему ставите? Пилите кулстори, как вы добрались до этой кнопки, уж очень любопытно
Очень просто: полез в гугл смотреть, что это такое. Вышел на официальный сайт. Правда, внезапно, весь мир не крутится вокруг Python и pandas?
И, да, пакеты я предпочитаю прежде всего ставить из состава поставляющихся с ОС. Так как знаю цену этой работе, равно как и цену легко разводимому всеми этими pip/gem/etc. бардаку, будучи мейнтейнером как лёгкого, так и довольно тяжёлого софта.
Я без понятия, кто ещё пользуется этим функционалом. Это ссылка на официальном сайте, если оно нерабочее — какого хрена она там делает? А если этим официальным сайтом никто не пользуется, ну-у-у, сами догадаетесь? Это ваша логика, не моя. Не нравится, когда зеркалят? ;)
> Короче, потерпите
Даже не собирался. Я просто продемонстрировал наглядно, что подход у разных проектов (на примере Mercurial и pandas, причём предложил pandas, опять же, не я, а оппонент) немного разный, что обусловлено во многом спецификой решаемых задач. Там, где Mercurial дуют на воду, pandas смело перешли на новую версию Python. Перешли, ну и молодцы. Но говорить, мол, Вася-спортсмен пробежать марафон смог, почему Петя-инженер не может — как-то глупо.
>> И рассказал об этом на opennet, а не мейнтейнерам :)
> Я рассказал об этом человеку, который первый заговорил о pandas как о
> примере качественного крупного проекта, успешно мигрировавшего на Python 3.У вас странная манера судить о качестве продукта. Битая ссылка, которая никому
особо не нужна. По хорошему, надо тестировать и ловить такие вещи. Вы хотите
сказать, что на openbsd.org я не найду битых ссылок?Есть NLOC для оценки объема кода, вполне можно сравнить с hq. Есть какой-нибудь
Scopus для оценки цитируемости статей проекта и его "успешности".> Я без понятия, кто ещё пользуется этим функционалом. Это ссылка на официальном
> сайте, если оно нерабочее — какого хрена она там делает?Баги бывают, странно не это - а то, причем тут вообще Python 3.
> А если этим официальным сайтом никто не пользуется, ну-у-у, сами догадаетесь?
Да пользуются, конечно, просто не для скачивания rc версий.
>>> И рассказал об этом на opennet, а не мейнтейнерам :)
>> Я рассказал об этом человеку, который первый заговорил о pandas как о
>> примере качественного крупного проекта, успешно мигрировавшего на Python 3.
> У вас странная манера судить о качестве продукта.Я всего лишь зеркалил ущербную логику оппонента. Странно, что вам это надо объяснять.
> Битая ссылка, которая никому особо не нужна.
Не надо судить обо всех по себе, ОК?
> По хорошему, надо тестировать и ловить такие вещи.
> Вы хотите
> сказать, что на openbsd.org я не найду битых ссылок?Найдите и сообщите. Скажу спасибо.
> Есть NLOC для оценки объема кода, вполне можно сравнить с hq.
> Есть какой-нибудь
> Scopus для оценки цитируемости статей проекта и его "успешности".Упоминания в прессе (и вообще в Сети) — мерка та ещё. Так как у продукта с меньшим количеством проблем в использовании упоминаний будет меньше. ;) Нет, получше метрику я пока что сам назвать не могу к сожалению... Ну да и не в них суть.
>> Я без понятия, кто ещё пользуется этим функционалом. Это ссылка на официальном
>> сайте, если оно нерабочее — какого хрена она там делает?
> Баги бывают, странно не это - а то, причем тут вообще Python
> 3.При том же, причём pandas к Mercurial: ровно ни при чём.
>> А если этим официальным сайтом никто не пользуется, ну-у-у, сами догадаетесь?
> Да пользуются, конечно, просто не для скачивания rc версий.Тогда зачем там эта ссылка размещена? А? :)
> Я всего лишь зеркалил ущербную логику оппонента. Странно, что вам это надо объяснять.Как-бы я ваш оппонент, получается. Так что ежели уж я не вижу у вас даже
тени логики - может таки стоит попытаться объяснить?>> Битая ссылка, которая никому особо не нужна.
> Не надо судить обо всех по себе, ОК?Я же вам, вроде, подробно объяснил почему этим не пользуются?
Да, можно добавить в CI ходьбу по ссылкам вебсайта с криками
на непонятные 4xx и 5xx ошибки. Беда в том, что это не очень
хорошо работает, особенно если вы ссылаетесь на сторонний сайт.
В данном случае просто "повезло", что в случае проблемы мы
получили 404. На куче сайтов вы получите 200 и о баге
вы узнаете только когда вам кто-то сообщит.>> Есть NLOC для оценки объема кода, вполне можно сравнить с hq.
>> Есть какой-нибудь
>> Scopus для оценки цитируемости статей проекта и его "успешности".
> Упоминания в прессе (и вообще в Сети) — мерка та ещё.Причем тут пресса? Я про цитируемость. В научной литературе
так делают, если используют какую-то программу.> При том же, причём pandas к Mercurial: ровно ни при чём.
Да pandas к hq притом, что это похожие по объему кода проекты, только и всего. Т.е.
задача по портированию на py2/py3 совместимую кодовую базу должна быть
сопоставимой, верно?>>> А если этим официальным сайтом никто не пользуется, ну-у-у, сами догадаетесь?
>> Да пользуются, конечно, просто не для скачивания rc версий.
> Тогда зачем там эта ссылка размещена? А? :)Ну я правда не телепат! Возможно, чтобы была ссылка на документацию dev-версии.
>> Я всего лишь зеркалил ущербную логику оппонента. Странно, что вам это надо объяснять.
> Как-бы я ваш оппонент, получается. Так что ежели уж я не
> вижу у вас даже
> тени логики - может таки стоит попытаться объяснить?Объяснял уже несколько раз: говорить «pandas смог, почему же Mercurial не смочь?» не корректно. Во всяком случае, без вменяемого обоснования, почему эти проекты можно сравнивать.
У KDE и ядра Linux как бы тоже сопоставимый объём кода. Но качество, гм, несравнимое.
>>> Битая ссылка, которая никому особо не нужна.
>> Не надо судить обо всех по себе, ОК?
> Я же вам, вроде, подробно объяснил почему этим не пользуются?Вы нарочно глухим дурачком прикидываетесь? Вот, я воспользовался. Мэйнтейнеры в дистрибутивах такими ссылками пользуются. Но вы же только себя и свой use case видите, а другим в праве на существование отказываете, объявляя их неправильными. В то время как если бы разработчики pandas считали их неправильными, то и ссылок бы таких не было, неужели это никак нельзя осознать?
>>> Есть NLOC для оценки объема кода, вполне можно сравнить с hq.
>>> Есть какой-нибудь
>>> Scopus для оценки цитируемости статей проекта и его "успешности".
>> Упоминания в прессе (и вообще в Сети) — мерка та ещё.
> Причем тут пресса? Я про цитируемость. В научной литературе
> так делают, если используют какую-то программу.Угу. То есть если программу (напрямую) не используют в научных исследованиях, то её цитируемость будет что?..
>> При том же, причём pandas к Mercurial: ровно ни при чём.
> Да pandas к hq притом, что это похожие по объему кода проекты,
> только и всего. Т.е.
> задача по портированию на py2/py3 совместимую кодовую базу должна быть
> сопоставимой, верно?Нет, см. выше.
>>>> А если этим официальным сайтом никто не пользуется, ну-у-у, сами догадаетесь?
>>> Да пользуются, конечно, просто не для скачивания rc версий.
>> Тогда зачем там эта ссылка размещена? А? :)
> Ну я правда не телепат! Возможно, чтобы была ссылка на документацию
> dev-версии.Тогда бы и была ссылка только на документацию, не?
Мир немножечко больше, чем pip install. А какую таблетку глотать, синюю или красную, — вы выбираете далеко не один раз в жизни.
> Во всяком случае, без вменяемого обоснования, почему эти проекты можно сравнивать.Рука бойца колоть устала. Вам же объяснили почему: это проекты одинакового размера.
> У KDE и ядра Linux как бы тоже сопоставимый объём кода. Но
> качество, гм, несравнимое.Во-первых - KDE побольше эдак раза два (по openhub судя). Во-вторых, качество кода - вопрос
уже отдельный. Учитывая то, что pandas - де-факто стандарт и широко известен в узком
кругу, а hg - в своей нише особых успехов не достиг и теряет последнее...>>>> Битая ссылка, которая никому особо не нужна.
>>> Не надо судить обо всех по себе, ОК?
>> Я же вам, вроде, подробно объяснил почему этим не пользуются?
> Вы нарочно глухим дурачком прикидываетесь? Вот, я воспользовался. Мэйнтейнеры в дистрибутивах
> такими ссылками пользуются.Хорошо, что я не являюсь пользователем дистрибутивов с такими мэйнтейнерами...
> Но вы же только себя и свой use
> case видите, а другим в праве на существование отказываете, объявляя их неправильными.Нет, я просто объясняю почему подобную проблему не заметили. Потому что пользователи
pandas (скажем так, другие, не буду из жалости к вам называть их "нормальными"),
включая мэйнтейнеров в дистрибутивах - осиливают чтение документации перед установкой.> Угу. То есть если программу (напрямую) не используют в научных исследованиях, то
> её цитируемость будет что?..То для нее надо искать какие-то другие критерии популярности/востребованности.
>>> При том же, причём pandas к Mercurial: ровно ни при чём.
>> Да pandas к hq притом, что это похожие по объему кода проекты,
>> только и всего. Т.е.
>> задача по портированию на py2/py3 совместимую кодовую базу должна быть
>> сопоставимой, верно?
> Нет, см. выше.Выше - это были ваши претензии к качеству кода? Ну, мне они продолжают казаться
странными. Ведь они даже не затрагивают код проекта, нес па?> Тогда бы и была ссылка только на документацию, не?
Я не вполне представляю, зачем они дают ссылки на архивы pypi. Это как-бы
недокументированный способ установки. Ну вот, чтобы было.> Мир немножечко больше, чем pip install.
Даже если это как-бы официальный способ установки данной программы?
> Рука бойца колоть устала. Вам же объяснили почему: это проекты одинакового размера.Кроме размера есть еще такое понятие как качество. Но когда пишут на питоне - речь про это как правило не идет. Какое качество у картонного макета? Да и зачем оно ему?
> Но когда пишут на питоне - речь про это как правило не идет.Т.е. вы не можете по этому параметру сравнить два проекта на питоне? Ну так
нафига вспомнили об этом и какие тогда претензии ко мне?
То-есть я совсем другой тип и моя ремарка касалась исключительно аппеляций к размерам... навалить горы гуано - дело не хитрое. Хитрое - чтобы потом это не отлилось. С чем как показал сабж бывают жырные факапы.
> То-есть я совсем другой типУвы, не заметно...
> и моя ремарка касалась исключительно аппеляций к
> размерам... навалить горы гуано - дело не хитрое.Ну вот как-бы у большинства "гор гуано" с переходом на третий питон
было существенно лучше. Вы не считаете, что я убедительно это доказал?
> Увы, не заметно...
> было существенно лучше. Вы не считаете, что я убедительно это доказал?Не, не считаю - убунта версий 5 к ряду бодро репортила "новых версий не обнаружено". А если внутрь копнуть, оказывается, реально чекавший это скрипт вообще дох жестокой смертью с адовым стектрейсом, суть которого на самом деле сводится к "у вас версия питона не та". Питон видите ли достаточно высокоуровневый чтобы на такой бдыщ в одном из компонентов просто ... забить, продолжить работу и с чистой совестью сказать про то что новых версий нет. А в результате всегда полшестого и всегда пора пить чай. А новой версии нет и через пять лет. И хрен проссышь почему без целого расследования.
> Питон видите ли достаточно высокоуровневый чтобы на такой бдыщ в одном из
> компонентов просто ... забить, продолжить работу и с чистой совестью сказать
> про то что новых версий нет.А вы не думаете, что проблема была не в питоне, а в каком-нибудь
охвисном гении из каноникала, влепившем в подходящее место except без
указания подходящих исключений?
> А вы не думаете, что проблема была не в питоне, а в
> каком-нибудь охвисном гении из каноникала, влепившем в подходящее место except без
> указания подходящих исключений?Если б так прикалывались только эти компоненты - я бы в это поверил. Но это вообще довольно типичное поведение для питонятины. Посмотри чего творилось когда им 3.5 -> 3.6 перед релизом приспичило. Наверное потому что майнтайнить совсем уж obsolete 5 лет им все же не с руки и на момент релиза хочется версию посвежее. Но в багтрекере после этого случается просто ад.
> Но это вообще довольно типичное поведение для питонятины.На какой выборке вы оценили типичность и как?
> Посмотри чего творилось когда им 3.5 -> 3.6 перед релизом приспичило.
"Им" - это бубунту? Не использовал и не собираюсь.
> На какой выборке вы оценили типичность и как?На то что мне попадалось. А так то конечно, если майнтайнеры за тебя подолбались - то как бы тебе то уже проще, конечно...
> "Им" - это бубунту? Не использовал и не собираюсь.
Ну можешь посмотреть что творилось в дебиане когда перед релизом десятки питон до 3.6 подтянули. Сколько и каких пакетов огребли баги и их пришлось перетряхивать оптом.
>> На какой выборке вы оценили типичность и как?
> На то что мне попадалось.Т.е. как таковая статистика отсутствует, просто "я щетаю" было неудобно сразу писать?
>> "Им" - это бубунту? Не использовал и не собираюсь.
> Ну можешь посмотреть что творилось в дебиане когда перед релизом десятки питон
> до 3.6 подтянули.Могу и посмотреть. Показывайте.
> И, да, пакеты я предпочитаю прежде всего ставить из состава поставляющихся с ОС. Так как знаю цену этой работе, равно как и цену легко разводимому всеми этими pip/gem/etc. бардаку, будучи мейнтейнером как лёгкого, так и довольно тяжёлого софта.Что такое virtualenv и как им пользоваться -- это хорошие вопросы джуну на собес.
> примере качественного крупного проекта,
> Одна ссылка на сайте временно нерабочая
> Поздравляю, вы обделались.Л - Логика.
> Правда, внезапно, весь мир не крутится вокруг Python и pandas?
Ну вот сам же сказал, что не имеешь экспертизы. Куда лезешь?
===
Эффект Да́ннинга — Крю́гера — метакогнитивное искажение, которое заключается в том, что люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации
ru.wikipedia: https://bit.ly/2QXQnDV
>> И, да, пакеты я предпочитаю прежде всего ставить из состава поставляющихся с ОС. Так как знаю цену этой работе, равно как и цену легко разводимому всеми этими pip/gem/etc. бардаку, будучи мейнтейнером как лёгкого, так и довольно тяжёлого софта.
> Что такое virtualenv и как им пользоваться -- это хорошие вопросы джуну
> на собес.Если мне на собеседовании начнут рассказывать, как это здорово — плодить помой^Wvirtualenv, то я пойму, что передо мной настоящий разработчик на Python, да. Вот только я не про разработку, а про поддержку и развитие этого всего. Особенно с нынешней модой на «микросервисы».
И, да, разработчиком на Python я себя никогда не называл. Хотя правил чужого кода на этом языке, наверное, больше некоторых из тех, кто так себя называет (привет, WAF, привет, Samba).
>> примере качественного крупного проекта,
>> Одна ссылка на сайте временно нерабочая
>> Поздравляю, вы обделались.
> Л - Логика.Если бы Вы хотя бы чуть-чуть внимательно читали, что вам пишут, вы бы не пытались поставить рядом эти две мои фразы, относившиеся совсем к разным вещам. Так что не вам точно говорить про логику.
>> Правда, внезапно, весь мир не крутится вокруг Python и pandas?
> Ну вот сам же сказал, что не имеешь экспертизы. Куда лезешь?А это я разве начал указывать разработчикам Mercurial, что они неправильно поступили, стараясь сохранять поддержку Python 2 и заботясь о надёжности хранения данных, за которые отвечает разрабатываемая система?
> ===
> Эффект Да́ннинга — Крю́гера — метакогнитивное искажение, которое
> заключается в том, что люди, имеющие низкий уровень квалификации, делают ошибочные
> выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки
> в силу низкого уровня своей квалификации
> ru.wikipedia: https://bit.ly/2QXQnDVЗамечательно. Обычно, правда, формулируют проще, про бревно и соринку. К себе применить не пробовали?
> Особенно с нынешней модой на «микросервисы».А для этого вообще луше go какой-нибудь освоить, чтоли. Гугл с питона не просто же так уходит.
> Зашёл на сайт какой-нибудь pandas. Нажал «get pandas», «download». Получил 404.Ну сообщите об этом разработчикам, может они вдруг не знают. Извиняюсь, а зачем
вам надо именно rc? Кому реально надо - скорее всего все-равно использует pip для
установки, а об данной ссылке даже не слыхал.> Знаете, я лично как-то рад, что эти ребята не занимаются разработкой одной
> из систем управления версиями файлов, которой я пользуюсь.А что не так-то? Ну, битая ссылка, может что-то на pypi.org поменяли
для rc/beta/alpha релизов.
>> Зашёл на сайт какой-нибудь pandas. Нажал «get pandas», «download». Получил 404.
> Ну сообщите об этом разработчикам, может они вдруг не знают.Сообщил, сообщил, не волнуйтесь.
> Извиняюсь, а зачем вам надо именно rc?
Потому что если бы вдруг выяснилось, что оно мне надо и начать тыкать, проще глянуть RC: к тому времени как разберусь, релиз явно уже выйдет.
> Кому реально надо - скорее всего все-равно
> использует pip для
> установки, а об данной ссылке даже не слыхал.Мой оппонент привёл пример якобы успешно переехавшего на Python3 проекта. Я полез смотреть, что это такое. Путь гугл — оф.сайт — download чем неправилен, не могу понять?
>> Знаете, я лично как-то рад, что эти ребята не занимаются разработкой одной
>> из систем управления версиями файлов, которой я пользуюсь.
> А что не так-то? Ну, битая ссылка, может что-то на pypi.org
> поменяли
> для rc/beta/alpha релизов.Да оно понятно, что со всеми бывают. И проекту pandas я желаю только всего хорошего. Просто маленькая шпилька насчёт их аккуратности, которая в случае с разработкой VCS (о чём изначально речь-то) важна куда больше.
> Сообщил, сообщил, не волнуйтесь.Не вижу бага. Вы страдаете телепатией?
>> Извиняюсь, а зачем вам надо именно rc?
> Потому что если бы вдруг выяснилось, что оно мне надо и начать
> тыкать, проще глянуть RCВы понимаете, что RC - это RC, а не релиз, установка там может быть весьма
специфической. Не лучший способ знакомства, учитывая что у проекта есть
стабильные релизы.>> Кому реально надо - скорее всего все-равно
>> использует pip для
>> установки, а об данной ссылке даже не слыхал.
> Мой оппонент привёл пример якобы успешно переехавшего на Python3 проекта. Я полез
> смотреть, что это такое. Путь гугл — оф.сайт — download чем неправилен,
> не могу понять?Правильный, просто неиспользуемый теми, кто этим реально пользуется. Больше
чем уверен, что большинство устанавливает pip install, как, кстати, написано
в документации. Вы же ее читали, да?>>> Знаете, я лично как-то рад, что эти ребята не занимаются разработкой одной
>>> из систем управления версиями файлов, которой я пользуюсь.
>> А что не так-то? Ну, битая ссылка, может что-то на pypi.org
>> поменяли
>> для rc/beta/alpha релизов.
> Да оно понятно, что со всеми бывают. И проекту pandas я желаю
> только всего хорошего. Просто маленькая шпилька насчёт их аккуратностиДанная "шпилька" имеет чуть менее чем никакого отношения к исходникам pandas.
>> Сообщил, сообщил, не волнуйтесь.
> Не вижу бага. Вы страдаете телепатией?Нет, это вы страдаете невнимательностью, и я начинаю подозревать, что она переходит в некомпетентность, к сожалению.
У сайта pandas отдельный репозиторий. Интересно, почему я это знаю, а вы, вроде как знакомый с этой софтиной, — нет?
>>> Извиняюсь, а зачем вам надо именно rc?
>> Потому что если бы вдруг выяснилось, что оно мне надо и начать
>> тыкать, проще глянуть RC
> Вы понимаете, что RC - это RC, а не релиз, установка там
> может быть весьма
> специфической. Не лучший способ знакомства, учитывая что у проекта есть
> стабильные релизы.Я прекрасно знаю, что такое RC. Если процесс установки RC отличается от процесса установки релиза, то это не RC, а в лучшем случае бета. Мне казалось, что у pandas всё не настолько плохо, но если вы настаиваете — значит, лишь подтверждаете моё мнение, что подход к качеству продукта у pandas и Mercurial сильно разный, и сравнивать их не корректно.
>>> Кому реально надо - скорее всего все-равно
>>> использует pip для
>>> установки, а об данной ссылке даже не слыхал.
>> Мой оппонент привёл пример якобы успешно переехавшего на Python3 проекта. Я полез
>> смотреть, что это такое. Путь гугл — оф.сайт — download чем неправилен,
>> не могу понять?
> Правильный, просто неиспользуемый теми, кто этим реально пользуется. Больше
> чем уверен, что большинство устанавливает pip install, как, кстати, написано
> в документации. Вы же ее читали, да?Нет, мне было интересно поглядеть на исходники. Не шучу. Впрочем, вкладка «documentation» была открыта рядом в тот момент.
>>>> Знаете, я лично как-то рад, что эти ребята не занимаются разработкой одной
>>>> из систем управления версиями файлов, которой я пользуюсь.
>>> А что не так-то? Ну, битая ссылка, может что-то на pypi.org
>>> поменяли
>>> для rc/beta/alpha релизов.
>> Да оно понятно, что со всеми бывают. И проекту pandas я желаю
>> только всего хорошего. Просто маленькая шпилька насчёт их аккуратности
> Данная "шпилька" имеет чуть менее чем никакого отношения к исходникам pandas.Равно как и упоминание pandas в контексте переезда на Python 3. Повторюсь, за проект я рад и желаю ему всяческих успехов. Но при этом я ничуть не менее рад, что Mercurial разрабатывается нЭмножЭчко по-другому.
> У сайта pandas отдельный репозиторий. Интересно, почему я это знаю, а вы,
> вроде как знакомый с этой софтиной, — нет?В смысле "отдельный"? От чего отдельный и причем это вообще тут?
> Я прекрасно знаю, что такое RC. Если процесс установки RC отличается от
> процесса установки релиза, то это не RC, а в лучшем случае бета.Вы сами так решили или какой дурак сказал? Это может в openbsd процесс установки
не меняется со времен 5-ти дюймовых дискет. А вообще - ничто не запрещает в
новом релизе устанавливать программу совершенно иначе, новые зависимости
там требовать и т.п.> Нет, мне было интересно поглядеть на исходники. Не шучу.
Ну так исходный код доступен, зачем было вообще что-то
устанавливать? Или у вас какие-то религиозные табу,
связанные с git?> Впрочем, вкладка «documentation» была открыта рядом в тот момент.
Но чукча не читатель. Я начинаю прозревать суть.
>> Данная "шпилька" имеет чуть менее чем никакого отношения к исходникам pandas.
> Равно как и упоминание pandas в контексте переезда на Python 3.Нет, не равно. pandas был выбран ровно по одной причине - сопоставимому размеру
кодовой базы. Вполне логичный выбор, нет?
>> У сайта pandas отдельный репозиторий. Интересно, почему я это знаю, а вы,
>> вроде как знакомый с этой софтиной, — нет?
> В смысле "отдельный"? От чего отдельный и причем это вообще тут?А как, интересно, вы проверяли, отправил ли я баг? И вы ушли от ответа, почему я разобрался, куда отправлять сообщения об ошибках на сайте, а вы — нет?
>> Я прекрасно знаю, что такое RC. Если процесс установки RC отличается от
>> процесса установки релиза, то это не RC, а в лучшем случае бета.
> Вы сами так решили или какой дурак сказал? Это может в
> openbsd процесс установки
> не меняется со времен 5-ти дюймовых дискет. А вообще - ничто
> не запрещает в
> новом релизе устанавливать программу совершенно иначе, новые зависимости
> там требовать и т.п.Вам расшифровать, что такое RC, и чем это отличается от alpha и beta, или всё же сами справитесь?
Если же для вас это всё едино, то, боюсь, наш разговор был изначально бессмысленным. Конечно, чисто технически разработчики могут называть что угодно как угодно, но это аргумент из серии «моя вещь, как хочу, так и называю».
>> Нет, мне было интересно поглядеть на исходники. Не шучу.
> Ну так исходный код доступен, зачем было вообще что-то
> устанавливать? Или у вас какие-то религиозные табу,
> связанные с git?Зачем мне качать весь репозиторий, если я хочу только глянуть на свежий срез исходников?
>> Впрочем, вкладка «documentation» была открыта рядом в тот момент.
> Но чукча не читатель. Я начинаю прозревать суть.Вы нихрена не прозреваете, а всё больше уходите в маразм.
Я. Хотел. Посмотреть. Исходники. Чисто в рамках темы сравнения с Mercurial. У вас какие-то фантазии же начались, что мне нужно. Спросить напрямую не судьба?
>>> Данная "шпилька" имеет чуть менее чем никакого отношения к исходникам pandas.
>> Равно как и упоминание pandas в контексте переезда на Python 3.
> Нет, не равно. pandas был выбран ровно по одной причине -
> сопоставимому размеру
> кодовой базы. Вполне логичный выбор, нет?Уже несколько раз я объяснял, почему нет. Вы упорно игнорируете мои слова, уходя в софистику. Разговор окончен.
> А как, интересно, вы проверяли, отправил ли я баг?По багтрекеру. На мой взгляд, это проблема основного проекта, хотя
технически связана с сайтом.> И вы ушли от ответа, почему я разобрался, куда отправлять сообщения
Гм., а с чего вы решили что разобрались? Из того, что у веб-сайта
отдельный реп совершенно не обязательно следует, что открывать баг
надо именно в нем. Вы хоть поискали аналогичные проблемы, куда
народ пишет?> Вам расшифровать, что такое RC, и чем это отличается от alpha и
> beta, или всё же сами справитесь?Расшифруйте. Мне до сих пор осталось непонятно почему я не могу изменить
порядок установки программы в новом релизе.>>> Нет, мне было интересно поглядеть на исходники. Не шучу.
>> Ну так исходный код доступен, зачем было вообще что-то
>> устанавливать? Или у вас какие-то религиозные табу,
>> связанные с git?
> Зачем мне качать весь репозиторий, если я хочу только глянуть на свежий
> срез исходников?А зачем его вообще качать? Взяли и посмотрели что нужно.
>>> Впрочем, вкладка «documentation» была открыта рядом в тот момент.
>> Но чукча не читатель. Я начинаю прозревать суть.
> Я. Хотел. Посмотреть. Исходники.Так, эта, там ссылка на github в разделе Development. С чего вы
вообще решили, что по "download" лежат в т.ч. исходники, а не
просто куча whl под разные платформы?>>>> Данная "шпилька" имеет чуть менее чем никакого отношения к исходникам pandas.
>>> Равно как и упоминание pandas в контексте переезда на Python 3.
>> Нет, не равно. pandas был выбран ровно по одной причине -
>> сопоставимому размеру
>> кодовой базы. Вполне логичный выбор, нет?
> Уже несколько раз я объяснял, почему нет. Вы упорно игнорируете мои слова,
> уходя в софистику. Разговор окончен.Ну вот, трогательно вспорхнул, облегчился и полетел... А как дысал!
>> А как, интересно, вы проверяли, отправил ли я баг?
>
> По багтрекеру. На мой взгляд, это проблема основного проекта, хотя
> технически связана с сайтом.Значит, твой взгляд сильно отличается от взгляда разработчиков Pandas: https://github.com/pandas-dev/pandas-website/issues/86
Интересно, ты извинишься перед Перерезусом? :)
> Значит, твой взгляд сильно отличается от взгляда разработчиков Pandas: https://github.com/pandas-dev/pandas-website/issues/86Да я уж понял, что он открыл баг в другом репе. Вы решили, что это правильно потому, что разработчки ему отвечают?
> Интересно, ты извинишься перед Перерезусом? :)
За что?
> За что?За напыщенное фееричное ламерство, например? Хоть я и не тот аноним и не перерезус, но тоже за что-то такое питонистов не жалую. Апломба - во, результата - во.
>> За что?
> За напыщенное фееричное ламерство, например?Может оно вам привиделось?
> Может оно вам привиделось?Походу не мне одному. А как минимум еще 1 анониму и перерезусу...
>> Может оно вам привиделось?
> Походу не мне одному. А как минимум еще 1 анониму и перерезусу...До миллионов мух и с этим далеко, конечно...
> До миллионов мух и с этим далеко, конечно...Дело хозяйское. Но репутацию питонистов таки деятельно подтверждает.
Лучше бы они его целиком на Rust переписали вместо этого
приступайте!
Уже приступил:
И что самое смешное, чтобы переехать на Rust, им всё равно надо сначала переехать на Python 3:«Mercurial still uses Python 2.7. Python 2.7 is officially compiled with MSVC 2008 and links against vcruntime90.dll. Rust and its standard library don't support MSVC 2008. They are likely linked with something newer, like MSVC 2015 or 2017.
If we want compatibility with other binary Python extensions, we need to use a Python built with MSVC 2008 and linked against msvcr90.dll.
So, our options are:
Build a custom Python 2.7 distribution with modern MSVC and drop support for 3rd party binary Python 2.7 extensions.
Switch Mercurial to Python 3 and build Rust code with same toolchain as Python we target.
Mix the CRTs.»
> https://www.mercurial-scm.org/wiki/OxidationPlanХипстеры как они есть - они там на самом деле модные моложедные ЯПы разучивают, а VCS вообще до кучи, побочный результат страдания этой фигней.
Вот этого точно не надо. Дайте Mercurial умереть спокойно.
> Лучше бы они его целиком на Rust переписали вместо этогоВзяв за основу git (как более успешный проект).
И назвать gitarust.
Гита - подразумевается женское имя.
Индийское.
А в английском (поработаю за КО) слово "гит" означает "мyдак". Скромняга Линус снова назвал своё детище в честь себя :)
В индийских [хинди-]языках женские имена заканчиваются на -и. На -а заканчивается уважительная мужская форма.
Мог удержаться, да автор комментария (154)...
> Лучше бы они его целиком на Rust переписали вместо этогоЭто чтобы оправдать зваиние пихтонрастов? :)
На расте уже пишут Пихуль.
Валентин Саввич?
Он вроде на расте не писал.
https://pijul.org/ же ну
"комментируя комментатора - не-майнтейнер полагает, что решение использовать для dvcs модный-молодежный язычок, который каждый день новый, а поддержку прошлых версий по желанию левой пятки бросают - было большой ошибкой, и является примером того, как не надо поступать"
два чаю этому анониму
> модный-молодежный язычок
> first released in 1991Боюсь что когда вышел этот якобы модный-молодёжный язычок тебя ещё даже в планах небыло.
> Боюсь что когда вышел этот якобы модный-молодёжный язычок тебя ещё даже в планах небыло.Питон язык модный. И на нём пишет молодёжь.
Russian. Do you speak it?!
> Питон язык модный. И на нём пишет молодёжь.Пиши на COBOL! Будь не таким как все!
— Программист Соренсон приветствует тебя.
— Почему ты такая? Что с тобой случилось?
— Изучала КОБОЛ. Боль. Муки. Ужасные крики. Соренсон просила о помощи. Много дней и ночей. И явился свет. Свет предложил помошь. Соренсон изменилась. Теперь я свободный человек.
— Что такое КОБОЛ?
— КОБОЛ — это травма ума. Не используй его. Забудь это проклятое имя. КОБОЛ — боль. КОБОЛ — ненависть.
> Питон язык модный. И на нём пишет молодёжь.У той молодёжи, которая модно писала на нём лет 20 назад, уже дети выросли, и внуки появились.
Вебмакакой можно быть в и 60...
> Вебмакакой можно быть в и 60...Шестидесятилетних не знаю. Знаю сорокалетних бабуинов, которые пишут на Java. И одного шимпанзе, который на C++.
Непонятно только, при чём здесь питон.
> Непонятно только, при чём здесь питон.Ну он как бы low entry barrier, типа этакого современного варианта BASIC, чтоли. На том тоже можно было прогать почти что угодно. И работало ... ну вот примерно как программы на питоне. Нет, некоторые даже игры программили. Но постепенно утыкались в ограничения и перфоманс. Те кто всерьез - подтягивали знания, осваивали более приличные ЯПы. А те кто так, пострадать... ну и где вот их программы теперь? Мусор на питоне с периодом полураспада пару лет - будет там же.
>типа этакого современного варианта BASICна эту роль прекрасно подходит LUA, а не этот ужас
20? А-ха-ха-ха-ха.
Двадцать лет назад только-только вышел питон 2.0 и о нем вообще никто не знал.
"и на нем тут же написали yum", поправил, не благодари.
Скорее стоит вспомнить up2date, предшественник yum-а в RHEL. Тоже на Python.
Хотя кто его нынче вспомнит...
он ни разу не предшественник, он предшественник rhnЕго задачей было обновляться, а не отслеживать взаимозависимости и притаскивать недостающее.
и?о боже, я понял: если кто-то что-то написал на только что появившемся языке - то это значит... не, я так и не понял, что ты хотел сказать.
Да там всё просто: пишешь не на паскале — ты «вебмакака»™ aka «хвостатый»®.Тезис вполне понятен и прозрачен, красной нитью проходит через всё обсуждение.
ну как бы если на только что появившемся языке пишут довольно существенную часть инфраструктуры (причем до того - просто отсутствовавшую) популярного проекта - видимо, что-то таки мешало сделать то же самое на perl5.
Бредятина какая-то.
Хотя Opennet...
Нужно было сразу на Rust-е писать.
Он тоже модно-молодёжный.
Есть же нормальные, проверенные временем языки. Pascal, например.
макакам нормальные неизвестны - их вот в школе мучали паскалем - они запомнили паскаль. А после школы они запомнили хруст, игого и пихон с пехепе. Других языков в макачьей голове нет.
Последние лет 20, НЯЗ, в школе программирование не выходит дальше Лого и Бейсика (да и то, школа должна быть очень продвинутой), а в универе мучают в основном жабой и крестами, так что именно эти два языка определяют труЪ макаку.А на паскале пишут настоящие ветераны, которым плевать на моду и хипстерские подвороты.
> а в универе мучают в основном жабой и крестами, так что именно эти два языка определяют труЪ макаку.Ну вот у нас на кафедре высшей математики до недавнего времени изучение программирования начиналось, довольно логично для специфики кафедры, с MatLab/Octave, затем лучшего для понимания «как это работает» семестр C и семестр ассемблер, а на последних курсах ещё и я окунаю в мир текстовых шеллов. А в итоге всё равно больше половины студентов самостоятельно лезет в Python. Я смирился, и теперь у бакалавров половина курсовых по моему предмету (ОС) — ФС на базе FUSE, написанные на Python. Все довольны: у них — удобный им язык, у меня — лучше освоившие предмет студенты. :)
а мы потом слушаем сказочки что "fuse это всегда в разы медленнее и неэффективнее чем модуль в ядре" (к тому же он так прекрасно роняет его в panic)
> а мы потом слушаем сказочки что "fuse это всегда в разы медленнее
> и неэффективнее чем модуль в ядре"И что характерно, он в разу медленнее чем модуль в ядре. Проверено exFAT и NTFS. А если это еще и на питоне написать - там разница будет в дофига раз. Потому что питон не тормозит!111
> "комментируя комментатора - не-майнтейнер полагает, что решение использовать для dvcs модный-молодежный язычок, который каждый день новый, а поддержку прошлых версий по желанию левой пятки бросают - было большой ошибкой, и является примером того, как не надо поступать"Забыл самое главное — не просто по желанию левой пятки, а _неожиданно_ и без предупреждения.
Неожиданней прекращения поддержки второго питона в 2020 году может быть только снег в декабре для наших коммунальщиков.
от ее "ожидаемости", конечно же, само собой найдется время квалифицированных разработчиков (ведь развивать проект нинужна) для удалить весь код и начать с чистого листа, на новом модном "отдельном йезыке, а не каком-то там улучшении пихона2", как подавалась эта бесполезная новоделка.И да, не суметь скомпилировать современным Си-компилятором код прикладного софта, написанный с четверть века назад (причем он - будет работать правильно) - можно только в редких специальных случаях. Для которых не нужны никакие построчные тесты (которые еще тоже надо написать вместо кода проекта) - они сразу сфейлят компиляцию и будет понятно, что и где исправлять.
А код двадцатилетней давности на tcl/tk (до которых, в виду того что этому не учат, к счастью, в макачьих школах, не добрались руки деятельных идиотов, ломающих все, до чего дотронулись) и вовсе просто работает по сей день.
> (ведь развивать проект нинужна) для удалить весь код и начать с
> чистого листа, на новом модном "отдельном йезыке, а не каком-то там
> улучшении пихона2", как подавалась эта бесполезная новоделка.Ну вот такие интересные разработчики - оказывается, могут себе позволить взять лопаты и вместо улучшений и новых фич разгребать за гвидо. Если в таком виде это катит, может им и дворницкая лопата пойдет, так что никто не заметит разницы? :)
пока что наоборот - понемного разгребают, но не делают это приоритетом - о чем и написали, хотите надежности - оставайтесь на второй версии.
А тем кто "не смог поставить рядом 2 и 3"(c)опеннетная макака - дворницкую лопату доверять нельзя, лопату сломают и весь тротуар собачьим дерьмом обмажут.
> пока что наоборот - понемного разгребают, но не делают это приоритетом - о чем и написалиМы вроде одну и ту же новость прочитали. Но я увидел там "мигрировать тонны лапши на тройку сложнааа, приходится заниматься этим практически в одиночку в свободное от работы время, я устал и скоро уйду от вас".
Боюсь, им бесполезно объяснять. В их мире есть только те, кто одной левой выполняет их хотелки, и все остальные. Даже просто понять, что наличие отличных приоритетов не делает кого-то лучше или хуже, камне умнее или глупее, сим героям не дано. А уж провести серьёзный анализ, причём до того как что-нибудь ляпнуть — точно не их путь. :)А за тротуар не бойтесь, не измажут. Там только трынделка изо всех органов развита, максимум ещё пускалка пыли в глаза. Лопату если и знают, как держать, то только по картинкам, и силёнок даже чтобы сломать её не хватит.
> пока что наоборот - понемного разгребают, но не делают это приоритетом -
> о чем и написали, хотите надежности - оставайтесь на второй версии."Мы тут страдали легким прогрммизмом и сдуру вляпались, поэтому хрен его знает как выкручиваться, но если вам надо чтобы не глюкало - используйте неподдерживаемый антик, а мы там может быть что-нибудь и придумаем, например, новый ЯП поучим".
> А тем кто "не смог поставить рядом 2 и 3"(c)опеннетная макака - дворницкую лопату
> доверять нельзя, лопату сломают и весь тротуар собачьим дерьмом обмажут.Зато будут фирменный стиль держать - очень дешевые. За уборку участка можно не платить - манагер найдет там собачье дерьмо и не засчитает, да и лопату вычесть из зарплаты. Ну и вообще, ты же не хочешь чтобы любители low entry barrier при случае рулили поездом, самолетом или каким там еще опасным промышленным объектом, а? :)
Только С и Git незыблемы и вечны!
Про perl забыл.
К счастью, в последнее время его гробницу оскверняют всё реже.
если бы одна шибкопопулярная vcs не таскала ее примотанной к заднице - я бы в это поверил.
Советую почитать соседнюю новость. Там как раз про то, что осквернять гробницы — нехорошо.> Предложена начальная реализация переработанной команды "git add -i", позволяющей добавлять изменённое содержимое в интерактивном режиме, переписанная с Perl на Си. Ведётся аналогичная переработка команды "git add -p".
"начальная реализация" еще одной мелкой фигни. Ждите, ждите, еще лет десять - а пока извольте ставить перл на любую систему, где понадобилось что-то склонировать. (ну да, пихон там уже, разумеется, есть)
> "начальная реализация" еще одной мелкой фигни.Ну так перл в гите и нужен для нескольких мелких фиговин, вообще-то.
> Ждите, ждите, еще лет десять
Гит — не меркуриал, у него разработчики есть. Максимум года два.
>> "начальная реализация" еще одной мелкой фигни.
> Ну так перл в гите и нужен для нескольких мелких фиговин, вообще-то.из которых он и состоит - поскольку в противном случае в сторону юзера вместо хотя бы получеловеческого интерфейса будут смотреть только шестеренки и шкивы.
>> Ждите, ждите, еще лет десять
> Гит — не меркуриал, у него разработчики есть. Максимум года два.ждите, ждите.
7% — это "из которых он и состоит"?Ну ладно, окей, вы меня уели. Не вижу смысла продолжать спорить с таким умным и квалифицированным человеком, как вы.
> Комментируя ситуацию с Python 3 мэйнтейнер Mercurial считает, что решение по продвижению ломающего совместимость Python 3 и навязывание его как нового более правильного языка, при отсутствии актуальных для разработчиков прорывных улучшений, было большой ошибкойа на самом деле было большой ошибкой продолжать совместимость Меркуриала с python-2 ..
нужно было как можно раньше перевести Меркуриал на ветку 3 (в 2008 году!) и СРАЗУ забросить ветку 2 -- исправляя ошибки без какой либо оглядки на прошлое.
без рассредоточения сил на всякую постороннюю хрень.
но ведь что это за этот мусор в голове у людей был? поклонников/фанатов версии 2.
скакого хрена они так долго тянули время? на что надеялись? на то что ветку 3 отменят?
> что это за этот мусор в голове у людей был?Ну как это что. Написано же в новости: пытались обеспечить обратную совместимость со сторонними расширениями, написанными на втором питоне.
>обеспечить обратную совместимость с неподдерживаемым (было бы поддерживаемо - было бы портировано) гoвнoм мамонта, у которого заведомо не было будущего (неподдерживаемое же), написанном на языке без будущего (потому что зараннее ясно, что поддерживать второй питон бесконечно не будут, 3й и сделали потому, что второй всех достал).пофиксил.
Прямо как в суровом энтерпрайзе (кстати, у нас тут тоже коллективный плач по второму питону).
> Прямо как в суровом энтерпрайзе (кстати, у нас тут тоже коллективный плач
> по второму питону).вебмакакам и участь вебмакачья
>>в суровом энтерпрайзе (кстати, у нас тут тоже коллективный плач
>> по второму питону).
> вебмакакам и участь вебмакачьяПусть покупают подписку на python2 EEE LTS ESR.
предлагаешь замутить стартап?Хотя не, не покатит - тебе не дадут назвать интерпретатор python (и даже python2, хотя это вполне может что-то поломать), лицензидр...ры такие др...ры.
А cpython и так пока вроде не собирается бросать поддержку второй версии - но энтерпрайзным страдальцам не поможет, они же не могут трогать не свой код, с "#!env python
> предлагаешь замутить стартап?При такой тяге к разгребанию за другими - дворником все ж менее мучительно будет. Тут создатель ЯП забодался :)
настоящему энтерпрайзу никто не мешает спокойно пользоваться дальше вторым питоном.Ну или можно заплатить аутсорсеру за "поддержку". Обращайтесь, недорого.
> настоящему энтерпрайзу никто не мешает спокойно пользоваться дальше вторым питоном.Люблю теоретиков. Как работает система пакетов в питоне — не знает, но мнение имеет.
> Люблю теоретиков. Как работает система пакетов в питоне — не знает, но мнение имеет.классный у вас ентер-прайс. Каждый день, или просто при каждом запуске пипискает весь интернет в хомяк, да, разумеется, самых наираспоследних занимательных версий, только что из под хвоста?
Тогда простите, техподдержка ЭТОГО обойдется вам значительно дороже. Ну вы ж энтер-прайс, у вас лишних денег много.
P.S. у меня, конечно, есть target "reinvent-the-wheel", но я ж "теоретик", и запускал его прошлый раз еще той зимой. Поскольку совершенно не хочу ознакомиться внезапно с новыми-модными достижениями хвостатых.
Не каждый день, но в некоторых ситуациях (например, при наличии специфических --install-options) pip может переизобре^Wпересобирать wheels. Для этого ему нужны build dependencies, которые описываются согласно PEP 517 и на которые влиять невозможно. Разве что пересобрать пакет самому или загрузить в свой pypi. Например, пакет cryptography всегда тащит самый новый setuptools, а в последней версии, вышедшей пару дней назад, выпилили питон2. И это только начало фана.Как и любая продвинутая пакетная система, pip имеет огромное количество возможностей испортить жизнь при сборке, и никакое жёсткое указание версий в requirements не спасёт.
Хана вам.
> Не каждый день, но в некоторых ситуациях (например, при наличии специфических --install-options)
> pip может переизобре^Wпересобирать wheels. Для этого ему нужны build dependencies, которыев моем случае пересобрать - не получится,он не знает, из чего их собирать и как.
Разумеется, никакие неожиданные install-options на нас не свалятся, поэтому свою копию репо, надеюсь, все же держать не придется.
Лет на пару еще хватит, а там может и избавимся от пихона.
Конечно, вам виднее. Что-то, правда, мне подсказывает, что вы никогда не видели багов в VCS, влияющих на целостность репозитория, и никогда его не чинили. Потому что те, кто знает цену надёжности VCS, как мне почему-то кажется, не разделяют вашу позицию. И, да, я в их числе (нет, чинить приходилось не Mercurial).
мда, так ценят целостность репозиториев, что выбрали язык без типов и при этом даже тестами толком не покрылиИ - Инжиниринг
Git написан на?..
Неужели тоже на языке без типизации?
Ужас, как дальше жить?!?
perl, который который позволяет обфусцировать код прямо из коробки
> perl, который который позволяет обфусцировать код прямо из коробкитам на перле (и баше) написаны только вспомогательные утилиты (которые дергают в итоге бинарник сишный, например https://github.com/git/git/blob/53f9a3e157dbbc901a02ac2c7334...), причем с каждым релизом это говно выкидывают по мере возможности всё больше и больше
посмотри в исходники прежде чем умничать не в тему
> perlC 48.8%
Shell 35.7%
Perl 6.7%
Tcl 4.6%
Python 2.0%
Makefile 0.8%
Other 1.4%Хорошо нынче на перле пишут.
Ладно, можно было бы понять "git написан на shell", всё-таки заметный процент...
> Tcl 4.6%а это-то там где? tcl bindings столько занимают?
Здрастье, штатный GUI gitk на tcl/tk
аааа!!! У него есть "штатный gui!"
(в ужасе убегает в сторону ближайшего окна)
> Git написан на?..В основном на сях, с прослойками на шелле и перле местами. В сях типы таки есть.
В сях типы таки так себе.
> В сях типы таки так себе.Типы как типы, уж получше чем у всяких питоноявоскриптов - по крайней мере, компилер знает сколько под это выделять, бананы на лету не меняются на груши с непонятным результатом, и при попытке это сделать без явной декларации - компилер таки возбухает warning'ами и кому качество ПО не пофиг это чинят, а кому одноразовый макет, как на питоне - так там какой ЯП ни возьми, результат предсказуем.
>> Git написан на?..
> В основном на сях, с прослойками на шелле и перле местами.cloc git-2.25.0
Language files blank comment code
-----------------------------------------------------------------------------------
C 473 35176 29663 209198
Bourne Shell 1079 33464 13447 202936
Неплохой размер прослойки, однако.
> Неплохой размер прослойки, однако.это может быть сборочницей, а не необходимым для работы собранного.
И скорее всего так и есть.
>> Неплохой размер прослойки, однако.
> это может быть сборочницей, а не необходимым для работы собранного.
> И скорее всего так и есть.https://github.com/git/git/blob/master/contrib/git-resurrect.sh
https://github.com/git/git/blob/master/contrib/fast-import/g...
https://github.com/git/git/blob/master/git-merge-octopus.sh
https://github.com/git/git/blob/master/contrib/subtree/git-s...
https://www.opennet.dev/opennews/art.shtml?num=43057
> Выпуск распределенной системы управления исходными текстами Git 2.6.0
> 29.09.2015
> Реализации "git pull" и "git am" переписаны на языке Си...
https://www.opennet.dev/opennews/art.shtml?num=49751
> Выпуск распределенной системы управления исходными текстами Git 2.20
> 10.12.2018 09:46
> Реализации команд "git submodule update", "git rebase" и "git rebase -i" полностью переписаны на языке Сиhttps://www.opennet.dev/opennews/art.shtml?num=50202
> Выпуск распределенной системы управления исходными текстами Git 2.21
> 25.02.2019 10:07
> Некоторые части "git bisect", ранее реализованные на Shell, переписаны на языке Си;
> мда, так ценят целостность репозиториев, что выбрали язык без типов и при этом даже тестамитак ценят - что у них - получилось.
Я ни одного поломавшегося репозитория на hg не чинил, и вряд ли придется (нет, я не планирую ставить пятые версии, мне и без них не дует).
Репо из под vcs на языке с типами - да, приходилось регулярно.Пока вы писали бесполезные тесты для язычка с типами (вместо кода проекта) - у них просто работало.
Действительно вряд ли придется. Много у тебя вообще репозиториев на ртути было-то, чтобы их чинить?
> Действительно вряд ли придется. Много у тебя вообще репозиториев на ртути было-то,
> чтобы их чинить?больше чем на svn, во всяком случае (по очевидным причинам) - которому таки приходится чинить при любом чихе.
С git сравнить не могу, потому что там есть коммерческие прожекты, размером сильно побольше того что могло бы быть у меня даже в виде личных клонов. Ну да, тоже бывает - ломаются.Наверное это из-за perl?
> Пока вы писали бесполезные тесты для язычка с типами (вместо кода проекта)
> - у них просто работало.работало-работало, да вот перестало
(в ужасе убегает делать hg verify)не, врут - как работало, так и работает.
> (в ужасе убегает делать hg verify)
> не, врут - как работало, так и работает.автор говорит, что не должно, а у тебя работает
может, помоги пацанам, раз ты такой умный и, к тому же, фанбой их продукта?
> может, помоги пацанам, раз ты такой умный и, к тому же, фанбой
> их продукта?а, я не увидел твой никнейм, тогда ничего кроме комментов на опеннете от тебя ожидать не стоит :)
Вы тут сами с собой общаетесь?
> Вы тут сами с собой общаетесь?всего навсего не могу редактировать сообщения
автор говорит что могут быть проблемы у пользователей новых модных дистрибутивов, героически поебдивших python2. Я не являюсь пользователем модного дистрибутива.И фанбоем тоже - староват для этого.
Пользоваться - в своих проектах пользуюсь. И у меня работать - не перестало и не перестанет.
А вы продолжайте нести чепуху о том как все сломалось и ужос-ужос.
ну в немодных обещают питон2 дропнуть в 2024 (или 2025?)даже автор ртути признал неотвратимость этого момента, только ты до последнего за него держишься и вероятно надеешься что зубную пасту третьего питона кто-то запихнет обратно в тюбик
все эти инциденты типа новых версий GTK или Qt были хорошими примерами естесственного отбора -- реально нужный софт имеющий большое количество пользователей и разработчиков продолжал шагать в ногу со временем, а мертворожденный уходил в историю, даже нытьё обиженных авторов было такое же как у автора ртути в данной новости
во время почти каждого ломающего выпуска языка или фреймворка находились те, кто считал что "вот раньше было лучше" и в итоге это порождались высеры типа TDE
в итоге вместо того чтобы признать реальность (какой бы несправедливой она ни была по твоему мнению) и помочь любимому проекту с миграцией и/или покрытием тестами ты только воняешь что все вокруг неправы и пытаются напоить тебя смузи
> ну в немодных обещают питон2 дропнуть в 2024 (или 2025?)-rw-r--r-- 1 root root 118 Nov 2 2011 /etc/os-release
как ты думаешь, мне есть дело до этих обещалок?А в энтерпрайзном проекте, который я имею сомнительную честь обслуживать - решение уже принято, пихону - кирдык, и значительно ранее 2024го. Скрипач с каждый день новыми нотами - нинужен.
> даже автор ртути признал неотвратимость этого момента, только ты до последнего за
наоборот. автор признал бессмысленность попыток угнаться за механическим зайцем, формально объявив поддержку, а неформально - пообещав баги и глюки на протяжении нескольких лет. Учитывая озвученные им причины этих багов - от использования новых версий в питоне2 тоже следует по возможности воздерживаться.
> него держишься и вероятно надеешься что зубную пасту третьего питона кто-то
> запихнет обратно в тюбикпросто выпустят 3.999 пихон, опять несовместимый с прежними - и опять гончие припустят за зайцем изо всех сил. А как почти-почти догонят - опа, 4.1
> во время почти каждого ломающего выпуска языка или фреймворка находились те, кто
продолжал и продолжает пользоваться тем софтом, который им удобен, наплевав на мнение гончих. У тех черепная коробка плоская, там вообще непонятно, где мозгу-то поместиться.
> в итоге вместо того чтобы признать реальность (какой бы несправедливой она ни
> была по твоему мнению) и помочь любимому проекту с миграцией и/илизачем мне помогать сизифову труду, когда я могу просто продолжать свои проекты - они тоже на всяком немодном и немолодежном. Вполне сойдут и для hg какой-нибудь немодной версии 4.5, например.
Благо зависимостей из pypi ей не требуется.
> зачем мне помогать сизифову труду, когда я могу просто продолжать свои проекты
> - они тоже на всяком немодном и немолодежном. Вполне сойдут и
> для hg какой-нибудь немодной версии 4.5, например.Вместо продуктивной активности по добавлению тестов или сизифова труда по миграции на новый питон ты выбираешь сизифов труд бэкпортирования критических исправлений из апстрима в 4.5 (и заодно обратной конвертации кода патчей из питона 3 в питон 2)? Или твоя ртуть, как ей и положено, развернута на локалхосте с единственным пользователем, тобой?
>> для hg какой-нибудь немодной версии 4.5, например.
> Вместо продуктивной активности по добавлению тестов или сизифова труда по миграции на
> новый питон ты выбираешь сизифов труд бэкпортирования критических исправлений из апстриманазовите целое одно такое исправление и дату когда оно сделано?
И отдельно - расскажите, насколько оно "критическое" на самом деле.
Я помню только одну сравнительно серьезную проблему пятилетней давности, но и та возникала при работе с недоверенными репо, то есть была из пальца высосана - вы код-то из этого репо, что - собирать не планировали?Напоминаю, что любой человек, имеющий право записи в репо, может развалить вообще все репо к чертям, просто понакомитив туда мусора или вообще троянцев (у hg нет, конечно, forced push в терминах гита, но понамержив не то и не оттуда все равно можно понасоздавать проблем окружающим, если они не заметят подставу немедленно). Ущерба от злоупотребления вполне легальным доступом к репо, скорее всего, будет в миллион раз больше, чем от любого другого ужосанах который можно сотворить через критическую увизгвизьмость. Да и знаний и умений потребуется куда меньше.
> в 4.5 (и заодно обратной конвертации кода патчей из питона 3
> в питон 2)? Или твоя ртуть, как ей и положено, развернута
> на локалхосте с единственным пользователем, тобой?ну, может даже на паре десятков локалхостов (лет-то мне уже немало) с двумя-тремя человеками пользователями, остальные роботы тyповатые, или роботоподобные люди, они не считаются. Там где пользователь один - dvcs вроде как не особенно и нужна.
Проектов размером с мазилу у меня, естественно, нет - заведу парочку немедленно после того, как получу в наследство миллион, желательно не ржублей.
Тащить hg в энтерпрайз за пределами своей зоны ответственности, разумеется, тоже не планирую - мне нет никакого щастья "обучать" потом необучаемых, думающих что умеют пользоваться git (нет).
> назовите целое одно такое исправление и дату когда оно сделано?https://www.cvedetails.com/vulnerability-list/vendor_id-8291...
и это только то чему дали CVE, а сколько там просто мелких багов?
>> назовите целое одно такое исправление и дату когда оно сделано?
> https://www.cvedetails.com/vulnerability-list/vendor_id-8291...то есть назвать - вы не можете. Что и требовалось доказать.
> и это только то чему дали CVE, а сколько там просто мелких
> багов?тем кому пользоваться, а не сказки на опеннете о нисисюрна-нисисюрна сказывать - совершенно все равно.
продолжай себя утешать, что первым 6-и багам в списке, проявляющимся в том числе в 4.5, дали статус CVE просто по приколуа я лишь порадуюсь что не вхожу в число пользователей твоего репо-сервиса
> дали статус CVEглавное - веровать. Разбираться или просто понимать о чем речь - необязательно. ААААА CVE, БЕЛКАМ СРОЧНО ИСТЕРИТЬ!
> а я лишь порадуюсь что не вхожу в число пользователей твоего репо-сервиса
радуйся. Только прекрасный git на радостях обновить не забудь, там очередной rce недавно всплыл ;-)
ну вот и веруй, что никто не разобрался как эксплуатировать те возможностиа гит уже в начале недели обновился, только все равно для той RCE, что ты рассказываешь, нужно иметь право пуша (т.е. должен быть либо внутренний диверсант, которому потом по отложившимся на логсервере логам можно по шапке надавать, либо же у него должны как-то хитро увести учетку), так что это проблема всяких гитхабов и др репо-сервисов с публичной регистрацией, в отличии от https://cwe.mitre.org/data/definitions/285.html
кстати, судя по количеству RCE в ртути до 4.5, остается только догадываться что там еще могли бы найти, будь она так же популярна как гит
ну, вот тебе - точно не судьба. Ты так и не удосужился посмотреть описания? Или посмотрел-ни-слова-не понял, как обычно? Так что я могу спать совершенно спокойно.> а гит уже в начале недели обновился, только все равно для той RCE, что ты рассказываешь,
> нужно иметь право пушапонял, то есть гит - швятой, швятой. в нем и rce не rce, так, фигня мелкая.
> понял, то есть гит - швятой, швятой. в нем и rce не
> rce, так, фигня мелкая.Если ремота захочет тебе rce сделать, есть способы проще. Например, код тебе отгрузить чутка измененный :). При том если у трольвальдса "дерево хэшей" еще более-менее делает совсем уж левые вбросы паливными, а чтобы совсем хорошо есть gpg-подписи, то чего у этих питонмакак?
> что там еще могли бы найти, будь она так же популярна как гитДа наверняка море всего. Качество в софте на питоне и не ночевало - там кодят скорей быстрей, как на пожар. Поэтому если потыкать палочкой - в софте на питоне обычно много всего находится.
Я вот потыкал парочку чат-ботов на питоне. RCE правда не словил, зато в бесконечную рекурсию гомнокод ушел хорошо :)
> так ценят - что у них - получилось.У них получилось. Облажаться на публику...
будущее Python 3 тогда было туманным, его судьба могла сложиться как у Perl 6
прямо все 12 лет с 2008-го года было туманным?
а когда жареный петух в жoпу клюнул -- че-то резко всё прояснилось сразу
> прямо все 12 лет с 2008-го года было туманным?До 1 января 2020 никто не верил, что это всерьёз. Думали, завтра проснутся, а нет никакого третьего питона.
А в третьей ветке великолепная обратная совместимость с самой собой. Да, анон? :)
> А в третьей ветке великолепная обратная совместимость с самой собой. Да, анон? :)Именно поэтому в демьяне майнтайнеры откалывали знатные тантры перед релизом, после апгрейда minor версии этой шляпы как обычно сломалось половина пакетов. Очень здорово, когда релиз на носу.
>> А в третьей ветке великолепная обратная совместимость с самой собой. Да, анон? :)
> Именно поэтому в демьяне майнтайнеры откалывали знатные тантры перед релизом, после апгрейда
> minor версии этой шляпы как обычно сломалось половина пакетов. Очень здорово,
> когда релиз на носу.Если б только в Debian. Все, кто независимую пакетную базу поддерживает, наелись. Да и до сих пор нет-нет, да и встретятся где-нибудь в зависимостях модули, из которых один уже только Py3, а другой ещё только под Py2, и фиг второй обновишь, так как из-за этого ломается что-то ещё, чем тоже люди пользуются.
Ну так если не заметили, многие уже с питоном наигрались и наелись вот такого счастья. Начиная с его создателя, который обнаружил что оказывается эксплуатация в промышленных масштабах - немного не о том чтобы страдать любой фигней себе в удовольствие :)))
Меркуриал модульный, для него написана масса сторонних расширений. Такой переход означал бы, что каждый разработчик расширения должен их все переписать, причем быстро и решительно.Можете сами вспомнить судьбу проектов, забивших болт на обратную совместимость со сторонними модулями.
Да, должны. Не смогли - до свидания. Ваше расширение очень важно для нас. Настолько важно, что портировать путём 2to3 -nw ./ некому.Картины дельфинов и тюленей мне даром не нужны. Творения не осиливших одну консольную команду - тоже.
Тут недавно FF стороение дополнения дррпнул
> Тут недавно FF стороение дополнения дррпнулНу так у него юзербаза за это тоже неплохо дропнулась. Скоро придется им быть шкуркой к хромиуму, на остальное все-равно програмеров и ресурсов не останется.
Ух ты, все решается одной консольной командой? Срочно расскажите разработчикам mercurial, а то у них там проблемы, говорят, нестабильный у них порт, ошибки пару лет вылезать будет. Тупые, видимо, не знали про команду-то!
Вот ты и расскажи. Я тольго гитом пользуюсь из VCS.
> Тупые, видимокод на питоне без тестов только умные и пишут
Обкладывать картонный макет программы тестами? Хы.
> Обкладывать картонный макет программы тестами? Хы.ну перед тем как переписывать с макета на чистовик по-нормальному - да, обкладывать тестами, чтобы не-макет работал так как задумывалось во время макетирования
> ну перед тем как переписывать с макета на чистовик по-нормальному - да,
> обкладывать тестами, чтобы не-макет работал так как задумывалось во время макетированияюнит-тесты так не работают.
Впрочем, и волшебной панацеей тоже не являются.
Обложить макет тестами. А потом подумать - тесты мол, некачественные, давайте их тоже обложим тестами. А потом...
> юнит-тесты так не работают.
> Впрочем, и волшебной панацеей тоже не являются.просвяти всех как они работают :D особенно в контексте рефакторинга прототипа в конечный продукт
> просвяти всех как они работают :DУ него врядли есть духовный сан с таким то ником...
> особенно в контексте рефакторинга прототипа в конечный продукт
Если про юнит тесты, это примерно так:
- Прога пилится на относительно простые и проверяемые компоненты (юниты).
- Програмер примерно представляет себе как по задумке должен работать его компонент.
- Програмер пишет тест своему юниту, скармливающий коду те или иные параметры и проверяющий что реакция на это и правда такая как задумано.На самом деле хорошая штука чтобы "прозвонить" логику работы своего кода и словить в ней косяки, одна из основ test driven development. Из минусов: тратит время програмера и таки не панацея: даже если все юниттесты проехали, на стыках взаимодействия все-равно случится какое-нибудь г. Да и все мыслимые варианты перебрать не всегда возможно.
для этого и меряют покрытие тестамии это даже не говоря о том, что в большом проекте существуют не только юнит тесты но и функциональные и интеграционные
> и это даже не говоря о том, что в большом проекте существуют
> не только юнит тесты но и функциональные и интеграционныеЯсен перец. Правда и они тоже не панацея. Натурные эксперименты показали что если взять миллион мартышек, они всегда смогут нажать что-то чего разработчики не предусмотрели. По этому поводу самые прошаренные даже гоняют fuzzing тесты на своем добре.
согласен, забыл упомянуть про fuzzingно им обычно тестируют не совсем то же самое, что мартышки, и с неколько другими целями, чего уж там
или уже есть фрейморки для fuzzing-а UI?
так же я забыл упомянуть, что coverage обычно не учитывает диапазоны значений входных данных функций (да и со многими типами данных и нет такого понятия как диапазон значений), что также говорит в пользу фуззинга как одного из слоев тестов
> согласен, забыл упомянуть про fuzzingОтож. Особенно актуально для алгоритмов и прочей core-логики.
> или уже есть фрейморки для fuzzing-а UI?
А смысл? Даже если UI сделает что-то ну вообще совсем не то - нижний уровень должен поймать и зарубить. Это особенно актуально для всякого веба, где какая разница чего там вебморда проверит, если атакующий потом все-равно скрафтит данные так как ему надо и пошлет их вообще другими способами?
В более обычных апликухах fuzzing UI дает... что именно? Так то я видел автотесты патыющиеся клацать то что должно клацаться. И что не должно клацаться. Это конечно не все возможные заскоки UI ловит. Но fuzzing в основном для изничтожения уязвимостей связанной с обработкой входных данных практикуют - а уязвимость прямо в UI это все-таки нечто достаточно экзотичное. Хотя-бы потому что глубокую обработку входных данных обычно делает все-таки не UI.
> В более обычных апликухах fuzzing UI дает... что именно?я предполагаю, это могло бы сократить время написания тестов для UI и как замена "взять миллион мартышек, они всегда смогут нажать что-то чего разработчики не предусмотрели"
но не в целях поисках уязвимостей в ядре/бэкенде, а просто чтобы отловить баги в самом UI или взаимодействии его с основным кодом
> я предполагаю, это могло бы сократить время написания тестов для UI и
> как замена "взять миллион мартышек, они всегда смогут нажать что-то чего
> разработчики не предусмотрели"Частично делается заскриптованными тестами, но это специфично для прог и все-таки не fuzzing в том плане что именно рандомное взаимодействие с гуем... ээ... а как с вменяемыми затратами сил критерий для pass/fail сформулировать в случайном клацании гуя?
> но не в целях поисках уязвимостей в ядре/бэкенде, а просто чтобы отловить
> баги в самом UI или взаимодействии его с основным кодомНу просто fuzzing в основном используют для прозвона корректности логики алгоритмов и тому подобного, там он легко прикручивается и понятно как и почему это должно работать. А вот как это в контексте гуя реализовать - черт бы его знает. Для гуя критерий pass/fail сложнее оформить внятно.
ну да, пожалуй задать вручную BVA для GUI тестов будет проще чем пытаться использовать идеи из фуззинга
>Можете сами вспомнить судьбу проектов, забивших болт на обратную совместимость со сторонними модулями.Хром/Хромиум. Ничё, жив пока.
Ну да, можно подумать что hg ожидают радужные перспективы.
> а на самом деле было большой ошибкой продолжать совместимость Меркуриала с python-2 ..Большой ошибкой было использовать неподходящий инструмент для написания Mercurial. ;-)
Когда планируется большой проект, надо прикидывать его время жизни, экосистему и т.д. В общем, делать анализ требований. И тогда выяснится, что Python, который очень хорош для прототипирования, а не для написания долгоживущего системного ПО, не подходит.
Они одним только названием намекали что проект какой-то ... токсичный.
когда они это затевали - во-первых, надо было быстро (очень неудобно жить вообще без vcs, а вариантов было - неособо) во-вторых расширяемо (чтобы самим на каждый чих не бросаться кодить - а значит, какой-то простой и быстрый язык для ляпания extensions все равно был нужен).А пихон еще не "развивался" прыжками, когда каждый год новая несовместимая версия выходит - поддержка же совместимости в рамках ветки 2 не была особенно тяжелым грузом, от нее и отказались-то именно потому, что это никак нельзя было уложить в прокрустово ложе совместимости с 3.
> когда они это затевали - во-первых, надо было быстроДелается прототип; если взлетел, и понятно, что надолго - переписывается на что-то более стабильное (не обязательно языг Цэ). Питон - это язык с динамической типизацией и довольно неочевидной семантикой.
А в качестве чего-то более стабильного можно взять Ocaml, например. Это, по-сути, практически компилируемый Питон с другим синтаксисом.
> нужно было как можно раньше перевести Меркуриал на ветку 3 (в 2008 году!) и СРАЗУначать переводить на ветку 3.6 или какая она там стала в 2009м, внезапно-снова-несовместимая.
(в оригинале трогательная история о том как макаки ломали обработку не-юникодных строк два раза подряд) - и так раз в год. Поправил, не благодари. Таков, в принципе, весь смысл разработок чего-то долгоживущего на мертворожденных язычках.А новый код писать совершенно нинуна, ведь это ваше меркуриал вообще нинуна, все реальные пацаны используют только жыт и жытхап.
> скакого хрена они так долго тянули время? на что надеялись?
на то что у разработчиков, достаточно умных чтобы осознанно использовать не единственноверный шид, а что-то отдельностоящее, вполне хватит мозгов поставить такой интерпретатор, который ему требуется, а у авторов - не бросать вялое исправление совсем критичных багов только потому что нимодна-нимодна (никаких подвигов от них не требовалось).
Зря, конечно.
> Комментируя Python 3 мэйнтейнер Mercurial считает, что решение по продвижению ломающего совместимость Python 3 и позиционирование его как нового более правильного языка вместо постепенного наращивания функциональности и предоставления возможности инкрементальной адаптации приложений было большой ошибкой, применившей большой вред сообществу и являющейся примером того как не нужно поступать крупным проектам.Очень правильные слова. Это настолько болезненно - переходить с питона 2 на питон 3, что ощущение будто тебя обманывают: вроде бы язык один и тот же почти во всех случаях, но проще переписать программу на каком-то другом языке, чем думать где ещё может возникнуть проблема после перевода своей кодовой базы с 2 на 3 питон.
> ощущение будто тебя обманывают
> проще переписать программу на каком-то другом языке, чемДа уже который год говорю, где обманывают: посмотрите на то, в каком состоянии "готовности" находятся стандартные библиотеки. За тридцать-то лет языка они, небось, должны быть совсем в ином состоянии. =/
И таки да: проще переписать на другом языке, чем пытаться поддерживать что-либо на питоне. Даже пресловутый мёртвый перл5 заставлял меня в своё время удивляться на порядки меньше, нежели питон2.
Но ладно. Я сейчас опять ведь начну питоносpач... А так надоели фанаты оного... Короче, ребята, давайте сразу засчитывайте мне слив, ибо я спорить не намерен в этот раз. Все несогласные -- лесом. =/
> мёртвый перл5Не мертвый, а стабильный.)))
И это прекрасно, потому что предсказуемо.
> Не мертвый, а стабильный.)))Именно. Ну вон прога на C89. До сих пор компилится и работает. При желании ее даже можно менять если надо. И никто не орет что C89 - deprecated, дескать. Более того - требование все резко переписать... ну... а вы сможете грамотно переписать какое-нибудь крипто, или допустим рида-соломона? Для того чтобы не накосячить надо знать пару специфичных разделов математики, однако. Иначе потом переписанное будет глючным или даже уязвимым.
> И это прекрасно, потому что предсказуемо.
Некоторым нравится закинуть гранату в проект и посмотреть что будет :). Будет примерно вон то.
> Именно. Ну вон прога на C89. До сих пор компилится и работает.Хочешь расскажу где лежат исходники CPython 2.2, например? Вот прикинь, если тебе кровьизносу надо конкретную версию интерпретатора - я тебе разрешаю взять и использовать ее.
Так можно! Без разрешения Папы Римского! Не упустите свой шанс!
>> Именно. Ну вон прога на C89. До сих пор компилится и работает.
> Хочешь расскажу где лежат исходники CPython 2.2, например? Вот прикинь, еслихочешь я расскажу тебе страшное: и чтобы скомпилировать ту прогу на C89 - вовсе не надо искать в несуществующих архивах 89го года именно ту версию компилятора и героически ее ставить на любую систему, включая те на которые не очень ставится.
В этом, собственно, и отличие пока еще сохранившихся нормальных средств разработчика от хипстаподелок.
> хочешь я расскажу тебе страшное: и чтобы скомпилировать ту прогу на C89
> - вовсе не надо искать в несуществующих архивах 89го года именно
> ту версию компилятораНу да, бедные разработчики тянут весь зоопарк стандартов...
> В этом, собственно, и отличие пока еще сохранившихся нормальных средств разработчика от
> хипстаподелок.Только нормальные ср^W^Wконпиляторы давно уже можно в финал IOCCC приглашать вне конкурса.
>> хочешь я расскажу тебе страшное: и чтобы скомпилировать ту прогу на C89
>> - вовсе не надо искать в несуществующих архивах 89го года именно
>> ту версию компилятора
> Ну да, бедные разработчики тянут весь зоопарк стандартов...бедняжечки... Как же это оказывается сложно - просто держать шаловилвые ручонки - в опе, и ничего работающего ими не трогать за пределами того, что необходимо.
Но зато их разработка, пожалуй, проживет еще пол-века, а пихон - выкинут набижавшие новые поколения любителей все поломать и ничего путного не построить. В пользу еще какого-нибудь фуфла.
>> Ну да, бедные разработчики тянут весь зоопарк стандартов...
> бедняжечки... Как же это оказывается сложно - просто держать шаловилвые ручонки -
> в опе, и ничего работающего ими не трогать за пределами того, что необходимо.Ну вообще-то - это сложно. Приходится не просто "не трогать", а обставлять все больше мест
специальными костылями, пропорционально количеству поддерживаемых стандартов.Иной раз вы производите впечатление неглупого человека, а порой...
> Но зато их разработка, пожалуй, проживет еще пол-века
Ну, из стандартов C тоже кой-что выкидывают. В _этом_ смысле - язык точно
не проживет еще пол-века.> а пихон - выкинут набижавшие новые поколения любителей все поломать
Пайтон хоронят уже лет тридцать. "Stop! This is silly."
> Пайтон хоронят уже лет тридцать. "Stop! This is silly."При том в последнее время достигают в этом определенных успехов. Оплот пихтонрастов в виде гуголя и нескольких иных нагруженных сайтов что-то go полюбили.
> Ну да, бедные разработчики тянут весь зоопарк стандартов...Новые стандарты в массе своей - superset старых. За редким исключением. А так чтобы именно deprecate, с жестким вынесением совместимости - в сях и плюсах почти не практикуется. В отличие от.
> Только нормальные ср^W^Wконпиляторы давно уже можно в финал IOCCC приглашать вне конкурса.
Типа, интерпретеры питона сильно лучше? :)
> А так чтобы именно deprecate, с жестким вынесением совместимости - в сях
> и плюсах почти не практикуется.Тем не менее, быват, быват. Гениальные дизайнеры языка, планирующие на
полвека вперед - они на кисельных берегах сидят, молочных рек...>> Только нормальные ср^W^Wконпиляторы давно уже можно в финал IOCCC приглашать вне конкурса.
> Типа, интерпретеры питона сильно лучше? :)В любом большом проекте без поллитры не разберешься. Но не настолько все плохо.
> Тем не менее, быват, быват.Конкретные примеры? Я вот целый _1_ могу с наскока вспомнить. Крайне специфичный и потому ни разу не встречавшийся мне в диком виде. В отличие от скриптов которые на каждом углу.
Поэтому с практической точки зрения - старые программы и собираются и работают. Как максимум компилер из-за улучшения статического анализа может варнингов накинуть. А дальше уже по ситуации, если хочется, можно и исправить. А можно и забить, если экскурсия в код не была частью планов. С питоном так не катит - там скорее грохнется с адским стэктрейсом на полпути к финишу. И это неудобно - потому что довольно трудно понять сколько вокруг летающих роялей, пытающихся на тебя ВНЕЗАПНО упасть. Именно тогда когда это очень некстати.
> Гениальные дизайнеры языка, планирующие на
> полвека вперед - они на кисельных берегах сидят, молочных рек...Ну так питонисты сперва делают, потом думают. Не все же такие.
> В любом большом проекте без поллитры не разберешься.
Вот то-то и оно.
> Но не настолько все плохо.
Типа, BDFL от хорошей жизни сбежал? :)
> Поэтому с практической точки зрения - старые программы и собираются и работают.Ну соберите мне третьекеды на современной системе, что ли.
Да куда там кеды, тут уже и VirtualBox не самой свежей версии (5.2.6) - и тот не собирается без бубна. Еще ему gcc версии от 4 до 7 подавай, аналогично с LLVM для новых версий в 5 ветке (5.2.34+) "ваша версия LLVM слишком новая! C 8 и 9 проблемы в рантайме!"
# Check for gcc with version >= 3.2.
# We depend on a working gcc, if we fail terminate in every case.
...
log_failure "gcc version $cc_maj.$cc_min found, expected gcc 4.x...7.x"Про сборку его морды с Qt4, который отовсюду выкинули - не заикаюсь. Так ведь даже код для _Qt5_ придется править, тот же
#include <QButtonGroup>
вставлять, иначе компиляция завалится с "invalid use of incomplete type ‘class QButtonGroup’".В общем, если вы с наскока припоминаете только 1 пример, то в контексте обсуждения это просто говорит не в вашу пользу …
> Ну соберите мне третьекеды на современной системе, что ли.Проект TDE занимается как раз этим самым :)
> # Check for gcc with version >= 3.2.
> # We depend on a working gcc, if we fail terminate in every case.И в каком месте зацитированное вообще является сями? Это вроде кус билдсистемы какой-то. И то что его как-то странно сделали - ну так в билдсистеме можно что угодно написать. Билдсистема проверит и сделает что сказано, но при чем тут си это все-таки не поясняет.
> Так ведь даже код для _Qt5_ придется править, тот же
> #include <QButtonGroup> вставлять, иначе компиляция завалится с "invalid
> use of incomplete type ‘class QButtonGroup’".По сравнению с питоном - один инкоюд это не так уж плохо. Ну и вообще, это отдельная жирная сторонняя либа - к сям и плюсам это само по себе отношения не имеет. Поменять интерфейс компонента несовместимо с прошлыми версиями можно на любом ЯП умеющем в либы/компоненты вроде.
> В общем, если вы с наскока припоминаете только 1 пример, то в
> контексте обсуждения это просто говорит не в вашу пользу …А может не в мою? Мне кажется, кто-то не разобрался в технологиях, но мнение уже имеет.
>> Ну соберите мне третьекеды на современной системе, что ли.
> Проект TDE занимается как раз этим самым :)И? Хотите сказать, что раз целый отдельный проект занимается этим, то это однозначное доказательство "старые программы собираются и работают" в действии? Как-то не очень убедительно.
Неужто KDE1 и Qt1/2/3 тоже наверное влет соберуться? (нет)>> # Check for gcc with version >= 3.2.
>> # We depend on a working gcc, if we fail terminate in every case.
> И в каком месте зацитированное вообще является сями? Это вроде кус билдсистемы какой-то. И то что его как-то странно сделали - ну так
> в билдсистеме можно что угодно написать. Билдсистема проверит и сделает что
> сказано, но при чем тут си это все-таки не поясняет.До этого там было:
https://github.com/svn2github/virtualbox/commit/b05888fae993...
- log_failure "gcc version $cc_maj.$cc_min found, expected gcc 4.x, gcc 5.x or gcc 6.x"
+ log_failure "gcc version $cc_maj.$cc_min found, expected gcc 4.x...7.x"
Видимо, написали просто так, из любви к искусству, а не потому что постоянно что-то ломается в билде, по типу:
https://www.virtualbox.org/ticket/18624
>> Так ведь даже код для _Qt5_ придется править, тот же
>> #include <QButtonGroup> вставлять, иначе компиляция завалится с "invalid
>> use of incomplete type ‘class QButtonGroup’".
> По сравнению с питоном - один инкоюд это не так уж плохо.
> Ну и вообще, это отдельная жирная сторонняя либа - к сям
> и плюсам это само по себе отношения не имеет. Поменять интерфейс
> компонента несовместимо с прошлыми версиями можно на любом ЯП умеющем в
> либы/компоненты вроде.Угум, угум. Тум считаем, там не считаем, а вот тут вот - рыбу заворачивали!
Что совой о пень, что пнем о сову - результат вообще-то не сильно отличается для конечного пользователя. Это притом что VBox 5.2.6 вышел в 2018 году.
Впрочем, ничего нового или удивительного для тех, кто ментейнил или ментейнит парочку старых пакетов в более современном окружении.>> В общем, если вы с наскока припоминаете только 1 пример, то в
>> контексте обсуждения это просто говорит не в вашу пользу …
> А может не в мою? Мне кажется, кто-то не разобрался в технологиях,
> но мнение уже имеет.А мне кажется, кто-то почти-совсем-не-трехсотоанонимный, как частенько с ним бывает, ляпнул не особо подумав и теперь пустился в демагогию.
Потому что по существу вопроса тут 0 целых крен десятых, лишь передерг да оправдывания "по сравнению с питоном не страшно!".
> И? Хотите сказать, что раз целый отдельный проект занимается этим, то это
> однозначное доказательство "старые программы собираются и работают" в действии?Я хочу сказать что проблемы третьекедов вытекают не из компилеров и сей. А из
1) Того что на майнтенанс оных технологий подзабили.
2) Некоторые технологии кедов 3 стали несколько иррелевантны (e.g. dcop vs dbus) и это вообще не по линии ЯП.
3) Взаимодействие с либами на которые они завязаны и поддержка всего этого. К самим по себе сям чье-то там (не)желание вечно поддерживать третий куть не относится никак.Собственно сабжи откопали и перекомпилили стюардессу. А зачем откапывать? Все остальные на эту версию забили - только поэтому.
> Как-то не очень убедительно.Неужто KDE1 и Qt1/2/3 тоже наверное влет соберуться? (нет)
Если они и завалятся то явно не по линии ЯП и компилеров. Скорее по зависимостям от внешних компонентов, что к ЯП и компилерам не относится чуть менее чем никак, это взаимодействие компонентов. Тем не менее, прошареные некромансеры периодически такое собирают. И таки да, можно это сделать современным компилером - вот новый компилер этому как правило не мешает вообще совсем никак. Разве что варнингами активнее трындит. Какие-то исключения возможны наверное, но их немного и я никак не могу вспомнить - где надо перепахивать всю прогу по всей площади, как в питоне?
> постоянно что-то ломается в билде, по типу:
> https://www.virtualbox.org/ticket/18624При том опять же к ЯП и компилеру это относится довольно сбоку - это новомодные оптимизации странно играют с их чудесами. "As expected, the problem is with PCH -- Workaround: VBOX_WITHOUT_PRECOMPILED_HEADERS := 1".
> Угум, угум. Тум считаем, там не считаем, а вот тут вот - рыбу заворачивали!
Если сям и плюсам считать все кути и прочие - тогда питону посчитаем всякие Zope'ы, во! :)
> сильно отличается для конечного пользователя.
А зачем пользователю вообще что-то собирать, программить и прочее? Не понимаю. И тем не менее, сборка древних кед - это больше вообще по линии майнтенанса и интеграции чем програмизма, ЯП и компилеров. Потому что сам по себе яп и компилеры там как правило и не мешают особо.
> Впрочем, ничего нового или удивительного для тех, кто ментейнил или ментейнит парочку
> старых пакетов в более современном окружении.Вообще странноватое сочетание, свежий gcc с старым пакетом. Но это где-то на грани бага на самом деле. Правда я не очень в курсе чьего именно, мне от vbox ничего не надо по счастью, так что простите великодушно что я в его начинке копаться не буду.
> А мне кажется, кто-то почти-совсем-не-трехсотоанонимный, как частенько с ним бывает, ляпнул
> не особо подумав и теперь пустился в демагогию.Интересно же посмотреть чего высосут из пальца вебманки? Вот тут притащили за уши сторонние либы и даже раскопали какое-то чудесатое взаимодействие с гцц.
> да оправдывания "по сравнению с питоном не страшно!".
А я виноват что примерно так оно и обстоит? Во всяком случае я почему-то смог собрать ряд весьма античных штук без перепиливания половины кода. С питоном так не катит. И переводы стрелок на сторонние либы - как-то не комильфо, тогда давайте и питону всякие zope'ы считать, вот уж мало не покажется.
>> Тем не менее, быват, быват.
> Конкретные примеры? Я вот целый _1_ могу с наскока вспомнить. Крайне специфичный
> и потому ни разу не встречавшийся мне в диком виде.Да берете стандарт и просто делаете поиск. В С11, например, gets удалена. Или вот,
в C99 добавили ключевое слово restrict.> В отличие от скриптов которые на каждом углу.
Ну прям так на каждом? Используйте нужный вам интерпретатор - и все будет
работать до морковкина заговенья.Чаще всего меняется что-то в стандартной библиотеке, которая умеет несколько
больше чем libc. И что будет если взглянуть как обстоит дело с обратной
совместимости в 100500 сторонних сишных либах?> Поэтому с практической точки зрения - старые программы и собираются и работают.
Да, покуда компиляторы тащат с собой поддержку стандартов языка ажно из конца
80-х прошлого века.> Как максимум компилер из-за улучшения статического анализа может варнингов накинуть. А
> дальше уже по ситуации, если хочется, можно и исправить.Да нет. "int restrict = 1;" - и усе, просто не соберется.
> С питоном так не катит - там скорее грохнется с адским стэктрейсом
> на полпути к финишу. И это неудобно - потому что довольно
> трудно понять сколько вокруг летающих роялей, пытающихся на тебя ВНЕЗАПНО упасть.Во-первых, это уже из области "динамические языки - это плохо". А с обратной совместимостью
в питон приблизительно также как и том же C. Да, чаще ломают (что неудивительно,
поскольку возможности искаропки несравнимы), но никогда ВНЕЗАПНО. Что-то
объявляется устаревшим, а уж потом в следующих релизах выкидывается.
Везде так. Никто серебряной пули не придумал.>> Гениальные дизайнеры языка, планирующие на
>> полвека вперед - они на кисельных берегах сидят, молочных рек...
> Ну так питонисты сперва делают, потом думают. Не все же такие.Где не такие - я только что написал выше. Удачи попасть в Воображляндию.
>> Но не настолько все плохо.
> Типа, BDFL от хорошей жизни сбежал? :)Хорошо что просто сбежал, а мог бы и ножичком, после стольких-то лет
подобной собачьей должности...
> В С11, например, gets удалена.Как "inherently dangerous function". И тем не менее, C89 код таки соберется. В режиме C89, разумеется. А я разве обещал что C89 код по мановению волшебной палочки станет C11? :)
Более того - в C89 и коменты с // нельзя начинать и в режиме C89 без расширений компилер имеет полное право завернуть такой код.
> Или вот, в C99 добавили ключевое слово restrict.
Но вот C89 проги как собирались так и собираются. А хотя-бы и в режиме C89 - потому что C99 отличается не только, блин, названием. И там даже типы лучше использовать другие - менее долбанутые чем в изначальном си. Потому что int something - это достаточно абстрактно, int бывают разными по возможностям, в зависимости от чудачеств платформы и компилера. В C99 это исправили, сделав куда более разумные типы - потому что писать на именно C89 без расширений код... какая-нибудь мелкая букашка типа pic может иметь свое мнение о том что такое int. Ну или у некоторых DSP например char 16-битный. Формально это валидно, фигли. А реально - поэтому и придумали C99 с явно озвученным числом битов на тип, так куда пресказуемее.
> Ну прям так на каждом? Используйте нужный вам интерпретатор - и
> все будет работать до морковкина заговенья.Gcc мне почему-то одной версии достаточно на все оказии, а тут предлагается террариум какой-то развести. Почувствуйте разницу.
> Чаще всего меняется что-то в стандартной библиотеке, которая умеет несколько
> больше чем libc. И что будет если взглянуть как обстоит дело
> с обратной совместимости в 100500 сторонних сишных либах?Ну так может быть с стандартной библиотекой тоже надо уметь вовремя угомониться? Я конечно понимаю что очень круто запихнуть весь глобус в стандартную библиотеку, но жабисты говорят что с этим потом бывают некоторые нюансы...
> Да, покуда компиляторы тащат с собой поддержку стандартов языка ажно из конца
> 80-х прошлого века.Ну так пока у народа есть этот код и его работа народу требуется - его и таскают. А все сломать и потребовать всех с ножом к горлу переписать модно, молодежно ... э, блин, а кто вон тому поезду колеса крутить будет? Ну не ты же, хипстер, фирмварь на питончике быстро перенакорябаешь? С такой фирмварью он с рельсов улетит или спалит ящик силовой электроники, стоящей больше чем твоя зарплата за год. Вот и таскают.
> Да нет. "int restrict = 1;" - и усе, просто не соберется.
Так никто и не обещал что любой код C89 собирается как C99. Иначе какой смысл вообще называть это новым стандартом? Можно и дальше говорить что это C89, разве не логично? :) Значит придется этот код как C89 билдить. У сишников так можно, в отличие от.
> Во-первых, это уже из области "динамические языки - это плохо".
И таки я считаю что это плохо.
1) Потому что гарантирует жоские проблемы с перфомансом.
2) Потому что статический анализ кода идет псу под хвост.По поводу чего начинаются ужимки с урезанными subset'ами которые типа не совсем питон, зато нет такие тормозливые. Но переписывать тонны гуано на это всем лениво - и они где-то там, влачат существование.
> А с обратной совместимостью в питон приблизительно также как и том же C.
Да вот не так же - у меня в системе только одна версия libc, одна версия компилера и проч. А компилить может и C11 и C89 и чего там еще. В случае с питоном же мне рассказывают что террариум - так и задумано. А ну его в пень такие задумки!
> Да, чаще ломают (что неудивительно, поскольку возможности искаропки несравнимы),
Ну насчет возможностей можно и поспорить. Я вот сишным кодом могу себе проц забутявить. Даже по сути без асма, без внешних рантаймов. А попробуйте так одним питоном, куле? :)
Ну и да, зачем вообще все переть в стандартную либу? Чтобы показать что муки жабистов при выпуске новой явы - еще не предел? Ну спасибо, это кажется удалось :)
> Везде так. Никто серебряной пули не придумал.
Не, вот пардон, я таки настаиваю что могу скомпилить и поюзать вон тот C89 код. Здесь и сейчас. А то что у меня компилер довольно новый - ну да, и чего?
> в Воображляндию.
Я бы сказал что с питоном светит только геморройлэнд и багодромы.
> Хорошо что просто сбежал, а мог бы и ножичком, после стольких-то лет
> подобной собачьей должности...Ножичком? Кого? Тех кто его творениями пользуется? Лучше гранату в этот обезьянник подбросить.
>> В С11, например, gets удалена.
> Как "inherently dangerous function". И тем не менее, C89 код таки соберется.
> В режиме C89, разумеется.Да, детка. Вы начинаете понимать принцип...
> А я разве обещал что C89 код
> по мановению волшебной палочки станет C11? :)Ну типа того: " Как максимум компилер из-за улучшения статического анализа может варнингов накинуть. А дальше уже по ситуации, если хочется, можно и исправить."
> Более того - в C89 и коменты с // нельзя начинать и
> в режиме C89 без расширений компилер имеет полное право завернуть такой код.Тоже неплохой пример.
>> Или вот, в C99 добавили ключевое слово restrict.
> Но вот C89 проги как собирались так и собираются.Пока вам достаточно стандартной библиотеки...
Ну так и конкретная версия интерпретатора пайтона - будет работать с
вашими скриптами как угодно долго.>> Ну прям так на каждом? Используйте нужный вам интерпретатор - и
>> все будет работать до морковкина заговенья.
> Gcc мне почему-то одной версии достаточно на все оказии, а тут предлагается
> террариум какой-то развести. Почувствуйте разницу.Во-первых, причем тут gcc? Аналогия, скорее, между стандартом языка и
версией интерпретатора. gcc - тащит несколько версий стандартов, интерпретатор
питона, грубо говоря - один (хотя пару релизов старые скрипты будут работать
с гарантией, разве что добавив в выхлоп предупреждений).Про gcc вам уже ответили граждане. То что вам достаточно жить ровно с одной версией
компилятора - говорит только о скудости опыта (хотя я бы уже рискнул сделать
более суровое обобщение).>> Чаще всего меняется что-то в стандартной библиотеке, которая умеет несколько
>> больше чем libc. И что будет если взглянуть как обстоит дело
>> с обратной совместимости в 100500 сторонних сишных либах?
> Ну так может быть с стандартной библиотекой тоже надо уметь вовремя угомониться?Так куда не запихни - получатся те же яйца.
>> Да, покуда компиляторы тащат с собой поддержку стандартов языка ажно из конца
>> 80-х прошлого века.
> Ну так пока у народа есть этот код и его работа народу
> требуется - его и таскают.Его таскают, в основном, из любви к закрытому коду корпорастов.
От них же и идут основные стоны про то как часто в питон что-то "ломают". Потому что
принцип остается прежний: "разработка" заключается в том, что слепили - и забыли.
В мире FOSS - совершенно другая картина. Большинство востребованных проектов на
питон - давно сумели свинтить на третий питон без стонов вроде сабжа.> А все сломать и потребовать всех
> с ножом к горлу переписать модно, молодежно ... э, блин, а
> кто вон тому поезду колеса крутить будет?На самом деле, вы не сможете найти мало-мальски серьезный открытый проект,
использующий какой-нибудь античный C89. Подавляющая часть адаптирована до
такой степени, что код как минимум собирается на наиболее современном стандарте.>> Да нет. "int restrict = 1;" - и усе, просто не соберется.
> Так никто и не обещал что любой код C89 собирается как C99.
> Иначе какой смысл вообще называть это новым стандартом?Ну кое-кто - обещал, см. выше. Конечно, я подозревал, что вы будете
юлить "я это не имел в виду, я это введу..."> У сишников так можно, в отличие от.
Мне вам что, картинки нарисовать как можно запускать скрипты с нужной
вам версией интерпретатора питон?>> Во-первых, это уже из области "динамические языки - это плохо".
> И таки я считаю что это плохо.Вам никто не запрещает так считать. Просто непонятно почему это мнение кого-то должно волновать?
>> А с обратной совместимостью в питон приблизительно также как и том же C.
> Да вот не так же - у меня в системе только одна
> версия libc, одна версия компилера и проч.Я вас поздравляю и даже немного завидую. Значит у вас все впереди! Может однажды поучаствуете
в разработке к-л свободного дистрибутива, а может даже в более серьезных вещах... ПТУ^WУниверситет там закончите или что там у вас.>> Да, чаще ломают (что неудивительно, поскольку возможности искаропки несравнимы),
> Ну насчет возможностей можно и поспорить.Ну об чем тут можно спорить? Что можно запилить поддержку json на C? Очереди
с приоритетом? Можно, конечно. Но мало кому в XXI веке уже интересно стругать
себе в 100500 раз инструменты из палок и г-на, есть масса более других задач.> Я вот сишным кодом могу себе проц забутявить.
Не уверен, что я понял вашу мову. Видимо, речь об использовании питона
для низкоуровневого программирования. В принципе, можно, только зачем?> Ну и да, зачем вообще все переть в стандартную либу?
Речь шла немного о другом: что вы сравниваете несравнимое. Т.е. чтобы быть
совсем уж честным при сравнении совместимости - вам надо посмотреть как обстоит
дело со всей кучей либ, которые обеспечивают для C функционал, сопоставимый
с питоновской стандартной библиотекой.>> Везде так. Никто серебряной пули не придумал.
> Не, вот пардон, я таки настаиваю что могу скомпилить и поюзать вон
> тот C89 код. Здесь и сейчас.Так и скрипт на питоне можно запустить нужной версией интерпретатора.
> Да, детка. Вы начинаете понимать принцип...Ну так в результате я могу юзать вон тот древний код с вот этим свежим компилером. Не патча полпланеты лично. Более того - можно даже сделать программу из разных по версии сей, это ни к чему такому не ведет.
> Ну типа того: " Как максимум компилер из-за улучшения статического анализа может
> варнингов накинуть. А дальше уже по ситуации, если хочется, можно и исправить."В каком месте здесь было обещание заапгрейдить соответствие кода стандартам? :)
> Тоже неплохой пример.
Ну дык. Однако те кто кодил под C89 и не юзали такие каменты. А если кто хотел фичу нового стандарта - ну вот тут придется проапгрейдить код уже. Но вот это - опционально. Можно забить, обойдясь без новых фич в этом файле.
> Пока вам достаточно стандартной библиотеки...
И иногда у меня даже и стандартной библиотеки нет. А где я на МК с простой как тапок фирмварой файловую систему возьму? :) А так расписываться за действия вообще всех програмеров и их либ - занятие провальное. Вон там zope, кстати, в соседней новости жжот, не к ночи будь поманут :)
> Ну так и конкретная версия интерпретатора пайтона - будет работать с
> вашими скриптами как угодно долго.А вот "конкретная версия интерпретатора" (или компилера) - намного менее удобное требование чем "конкретная версия стандарта".
> Во-первых, причем тут gcc? Аналогия, скорее, между стандартом языка и
> версией интерпретатора.Ну и вот с этим как бы грабли. Мне достаточно поставить 1 "системный" компилер из репов - и он прожует что у меня есть. А с питоном - фигвам, так не катит.
А если б мне надо было таскать по версии компилера на стандарт, да еще чтоб из проги на C99 хрен поюзаешь алгоритм на C89 - блин я б тогда наверное си "любил" так же как и питон.
> Про gcc вам уже ответили граждане. То что вам достаточно жить
> ровно с одной версией компилятора - говорит только о скудости опытаБулшит бинго. Никто из моих знакомых убер-гуру, вплоть до крутых игроделов и мощных алгоритмистов, не держит у себя зоопарк сишных компилеров. Одна версия на все.
Более того - майнтайнеры в дистре, внезапно, билдят одним компилером. По задумке - тем который в репах лежит.
> Так куда не запихни - получатся те же яйца.
А вот не те же. Если в стандартную либу пхать, отвалится у большего числа народа. А опциональная либа - там во первых програмеры дважды подумают до того как апи менять, под угрозой что их либу все перестанут юзать, а во вторых - половина обнаружит что им и без этой либы можно обойтись.
> Его таскают, в основном, из любви к закрытому коду корпорастов.
Расскажем DJB что его tweetnacl - "закрытый код корпорастов"?!
> принцип остается прежний: "разработка" заключается в том, что слепили - и забыли.
Я бы вот предпочел не совать свои лапки в tweetnacl без серьезной необходимости. Это довольно чревато в крипто и я не ощущаю себя DJB - он такой один.
> В мире FOSS - совершенно другая картина.Как-то не видел программистов которые с энтузиазмом бы рвались переписывать код не для того чтобы улучшить а потому что на их бошку новая версия свалилась.
> На самом деле, вы не сможете найти мало-мальски серьезный открытый проект,
> использующий какой-нибудь античный C89.А как насчет кода рида-соломона от Phil Karn? Он легенда в тематической области - вернул к жизни полудохлый КА, своими мега-знаниями в подобной вот алгоритмике. И он был достаточно щедр для того чтобы оформить частицу знания в либу рида-соломона. Которую разрбрали на цитаты. И которая таки C89.
> Подавляющая часть адаптирована до такой степени, что код как минимум
> собирается на наиболее современном стандарте.Да зачем? Они и как C89 прекрасно юзабельны. В том числе и проектами чей собственный код соответствует последним стандартам.
> Ну кое-кто - обещал, см. выше.
Цитату обещаний плз?
> Мне вам что, картинки нарисовать как можно запускать скрипты с нужной
> вам версией интерпретатора питон?Спасибо, но мне как-то по жизни оказалось проще найти аналоги на чем-нибудь другом. Поэтому на данный момент я уже не имею таких проблем.
> Просто непонятно почему это мнение кого-то должно волновать?
Ага, я за ним столько бежала, чтобы сказать ему что он мне пофиг... %)))
> в разработке к-л свободного дистрибутива, а может даже в более серьезных вещах...
> ПТУ^WУниверситет там закончите или что там у вас.Дык участвую. Но естественно не в пихоносрани с вебмакаками. Мне такой крап просто не интересен.
> Ну об чем тут можно спорить? Что можно запилить поддержку json на C?
> Очереди с приоритетом? [...]...поэтому сишники просто цепанут библиотеку - и дело в шляпе. Это ж не питон, где код в массе своей вымер, т.к. афтыри заколебались постоянно переписывать. У сишников библ - на все оказии. И таки к счастью не в стандартной блин либе. Ну вот накулкуа мне там какой-нибудь куть?
> Не уверен, что я понял вашу мову. Видимо, речь об использовании
> питона для низкоуровневого программирования. В принципе, можно,
> только зачем?Это ответ на реверанс что на питоне дескать можно все, бла-бла. И таки некоторые вещи на именно питоне без костылей на других ЯП - да удачи.
> дело со всей кучей либ, которые обеспечивают для C функционал, сопоставимый
> с питоновской стандартной библиотекой.И в результате получаем помесь явы с кутями, только еще хуже, когда после выпуска очередной версии наступает вешалка. Я вот как раз очень рад что те либы опциональные. Хочу - юзаю их, не хочу - не юзаю. И не имею стало быть проблем с ними и их развалом. Более того - чрезмерно ломкие либы постепенно отсеиваются. А если прямо стандартная либа изгадилась - как это отсеивать?! :D
> Так и скрипт на питоне можно запустить нужной версией интерпретатора.
Ну так в результате требуется устраивать террариум, да к тому же в репах дистра этого нет, что гарантирует кучу дурной камасутры на ровном месте. А таки удобно когда компилер можно прям из реп 1-2 командами, и потом все просто работает...
> А вот "конкретная версия интерпретатора" (или компилера) - намного менее удобное требование чем "конкретная версия стандарта".
> много бла ни о чем
> Булшит бинго. Никто из моих знакомых убер-гуру, вплоть до крутых игроделов и мощных алгоритмистов, не держит у себя зоопарк сишных компилеров. Одна версия на все.
> Более того - майнтайнеры в дистре, внезапно, билдят одним компилером. По задумке - тем который в репах лежит.То, что "это может быть любой компилер, если этот компилер - не слишком свежий gcc" - вы опять забыли упомянуть из скромности, из-за специфично-выборочного восприятия, незнания или банального склероза?
https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-lang/erla...
А вот тут вот штатный компилер вообще-то шланг:
https://www.freshports.org/lang/gcc9/
gcc9
This port is required by:
for Build
archivers/R-cran-zip
astro/R-cran-maptools
astro/nightfall
astro/wcslib
audio/calf-lv2
audio/gsequencer
audio/lsp-plugins-lv2
Expand this list (620 items / 613 hidden)Причем, список сильно сократился за последние пару лет, по мере наращивания шлангом компатибельности с gcc.
Совсем забыл:
> Никто из моих знакомых убер-гуру, вплоть до крутых игроделов и
> мощных алгоритмистов, не держит у себя зоопарк сишных компилеров. Одна версия на все.Помимо того, что сам аргумент перевода стрелок на "знакомых", без конкретных отсылок, разве что детсад^W лулзовый - мне просто интересно, как выглядел вопрос о кол. или версиях используемых компилеров? "Слышь, ты сколько компилеров используешь? Как все правильные пацаны, одну версию?"
В общем, хотите использовать аргумент "авторитета" - давайте проверяемый отссылки на пару более-менее серьезных кодеров.
А то и тут, если чуть копнуть, как-то не очень в вашу пользу выглядит:
https://lkml.org/lkml/2013/2/5/873
> All gcc versions tested (4.[4567]) emit calls to __bswap[sd]i2 when
> optimizing for size, so we add the !CC_OPTIMIZE_FOR_SIZE check.https://lkml.org/lkml/2018/3/21/775
> I tried putting the below ugly test code through various gcc versions.https://lkml.org/lkml/2019/8/7/55
> > I see the same warnings building linux-5.2.0 with gcc9. However, I don't see the warnings building linux-5.2.0 with the
> the 20190705 of gcc8.
>> Да, детка. Вы начинаете понимать принцип...
> Ну так в результате я могу юзать вон тот древний код с
> вот этим свежим компилером. Не патча полпланеты лично.Так и на питоне это можно.
> Более того -
> можно даже сделать программу из разных по версии сей, это ни
> к чему такому не ведет.И это по-идее, тоже можно. Хотя к чести питона, до сих пор подобных
гениев разработки мне встречать не довелось.>> Ну типа того: " Как максимум компилер из-за улучшения статического анализа может
>> варнингов накинуть. А дальше уже по ситуации, если хочется, можно и исправить."
> В каком месте здесь было обещание заапгрейдить соответствие кода стандартам? :)Послушайте, в "я имел в виду не то, я то введу" - играть с вами я не намерян.
> А если кто хотел фичу нового стандарта - ну вот
> тут придется проапгрейдить код уже.Угу, иначе register все подорвет... Т.е. с совместимостью обстоит
плюс-минус лапоть также как в питоне: мы объявляем что-то устаревшим,
чтобы в следующих стандартах удалить, мы вводим новый синтаксис, который
ломает нам старый код (кстати, примеров подобного как-то сходу не могу
придумать в питон, в отличие от)...>> Пока вам достаточно стандартной библиотеки...
> И иногда у меня даже и стандартной библиотеки нет. А где я
> на МК с простой как тапок фирмварой файловую систему возьму? :)
> А так расписываться за действия вообще всех програмеров и их либ
> - занятие провальное.Это вы все порываетесь расписываться, а я лишь констатировал факт. В стандартной
библиотеке даже нет большей части типовых структур данных. STL. Одна из причин
того, почему такая мерзкая гадость как C++ не сдохла в колыбели...>> Ну так и конкретная версия интерпретатора пайтона - будет работать с
>> вашими скриптами как угодно долго.
> А вот "конкретная версия интерпретатора" (или компилера) - намного менее удобное требование
> чем "конкретная версия стандарта".Почему? Это одно и то же. Или вам неприменно надо одобрямс чинуш из
ISO? Ну так тогда последний стандарт схемы - что-то типа r3rs...>> Во-первых, причем тут gcc? Аналогия, скорее, между стандартом языка и
>> версией интерпретатора.
> Ну и вот с этим как бы грабли. Мне достаточно поставить 1
> "системный" компилер из репов - и он прожует что у меня есть.Ну так проблема в том, что это _вам_ достаточно. А вот в дистрибутивах почему-то
держат несколько. И львиная доля проблем - это именно "мы заменили gcc на gcc, ПАМАЖИТЕ
ПАЖАЛУСТА!" Другой сценарий: какая-нибудь libxml2 поменяла версию.> А с питоном - фигвам, так не катит.
Почему? У меня ровно один системный интерпретатор.
> Более того - майнтайнеры в дистре, внезапно, билдят одним компилером. По задумке
> - тем который в репах лежит.Это смотря в каком дистре. А то в Debian вот почему-то gcc-7 и gcc-8... Шланг
тоже рядом лежит.>> Так куда не запихни - получатся те же яйца.
> А вот не те же. Если в стандартную либу пхать, отвалится у
> большего числа народа.Если вы не пользуетесь - что у вас может отвалиться?
> А опциональная либа - там во первых програмеры
> дважды подумают до того как апи менять, под угрозой что их
> либу все перестанут юзать, а во вторых - половина обнаружит что
> им и без этой либы можно обойтись.Вообще-то куда шустрее всякие libxml2 сишные апи меняют чем что-то
обратно-несовместимое в стандартной библиотеке питона сотворят...>> Его таскают, в основном, из любви к закрытому коду корпорастов.
> Расскажем DJB что его tweetnacl - "закрытый код корпорастов"?!Можете сразу рассказать как из-за одной из его 100500-й утилитки
в компайлерах держат кучу стандартов.>> принцип остается прежний: "разработка" заключается в том, что слепили - и забыли.
> Я бы вот предпочел не совать свои лапки в tweetnacl без серьезной
> необходимости. Это довольно чревато в крипто и я не ощущаю себя DJB - он такой один.Да не один он такой. Поматросил и бросил - типичная картина при
интырпрайз-разработке. А у автора кумыла просто с детства чвс чешется,
вот он и плодит новые мертворожденные проекты. Код для статьи.Не вспоминайте про DJB при тех, кто с его поделиями сталкивался в промышленном
применении. Могут и ногами побить.>> В мире FOSS - совершенно другая картина.
> Как-то не видел программистов которые с энтузиазмом бы рвались переписывать код не
> для того чтобы улучшить а потому что на их бошку новая версия свалилась.Ну а чего еще вы не видели? Тех кто пишет тесты?
>> На самом деле, вы не сможете найти мало-мальски серьезный открытый проект,
>> использующий какой-нибудь античный C89.
> А как насчет кода рида-соломона от Phil Karn? Он легенда в тематической
> области - вернул к жизни полудохлый КА, своими мега-знаниями в подобной
> вот алгоритмике. И он был достаточно щедр для того чтобы оформить
> частицу знания в либу рида-соломона. Которую разрбрали на цитаты. И которая таки C89.Проект настолько серьезен, что даже викимусорка его не упоминает,
пишущи про подобную "алгоритмику".Нет, проектов на манер DJB (запилю вам POC, "открою" под "хочите
менять - форкайте на всю катушку") - найти, наверно, можно. Хотя как раз
сишные проекты все меньше в этом плане заметны: тут именно Python удобнее.Я не про "открыл и забыл", а про проекты, у которых есть багтрекер,
хотя бы несколько разработчиков, сформировавшееся сообщество пользователей вокруг.>> Подавляющая часть адаптирована до такой степени, что код как минимум
>> собирается на наиболее современном стандарте.
> Да зачем? Они и как C89 прекрасно юзабельны. В том числе и
> проектами чей собственный код соответствует последним стандартам.Да все за тем же. Чтобы проект не подох в итоге. Никому не интересно
обучать вновь приходящих разработчиков ANSI C, например.>> Ну кое-кто - обещал, см. выше.
> Цитату обещаний плз?Я цитировал. См. выше, вы там в шкаф залезли "я это не введу, я введу другое"...
>> в разработке к-л свободного дистрибутива, а может даже в более серьезных вещах...
>> ПТУ^WУниверситет там закончите или что там у вас.
> Дык участвую. Но естественно не в пихоносрани с вебмакаками.Веб-проекты, мягко говоря, далеко не самая типичная область применения питона.
>> Ну об чем тут можно спорить? Что можно запилить поддержку json на C?
>> Очереди с приоритетом? [...]
> ...поэтому сишники просто цепанут библиотеку - и дело в шляпе.А потом просто цепанут ее немножко по-другому. Потому что тут АПИ
менять можно хоть каждый год - не стандарт. Же!> Это ж не питон, где код в массе своей вымер, т.к. афтыри заколебались
> постоянно переписывать.Давайте вы хоть что-то попробуете доказать. Благо, это не C, где код
лежит где попало и как попало. Все более-менее запаковано одинаково
и есть pypi, который уже не-веб-макака должна суметь за час распросить
про статистику. Дерзайте. Может даже вам для дипломной работы сгодится...>> дело со всей кучей либ, которые обеспечивают для C функционал, сопоставимый
>> с питоновской стандартной библиотекой.
> И в результате получаем помесь явы с кутями, только еще хуже, когда
> после выпуска очередной версии наступает вешалка. Я вот как раз очень
> рад что те либы опциональные. Хочу - юзаю их, не хочу - не юзаю.Если вы их не юзаете - то каким образом ожидаете от них "вешалку"?
> А если прямо стандартная либа изгадилась - как это отсеивать?! :D
А что мешает сделать нестандартную либу? Следовательно, вы доказали
только то, что стандартная либа "не изгадилась", с совместимостью
там все хорошо.>> Так и скрипт на питоне можно запустить нужной версией интерпретатора.
> Ну так в результате требуется устраивать террариум, да к тому же в
> репах дистра этого нетПочему это террариум, а куча стандартов в компиляторе - не террариум?
И почему это в репах дистра "нет"? Как правило, все есть - для
самого актуального случая (py2 vs py3).
>[оверквотинг удален]
> в режиме C89 - потому что C99 отличается не только, блин,
> названием. И там даже типы лучше использовать другие - менее долбанутые
> чем в изначальном си. Потому что int something - это достаточно
> абстрактно, int бывают разными по возможностям, в зависимости от чудачеств платформы
> и компилера. В C99 это исправили, сделав куда более разумные типы
> - потому что писать на именно C89 без расширений код... какая-нибудь
> мелкая букашка типа pic может иметь свое мнение о том что
> такое int. Ну или у некоторых DSP например char 16-битный. Формально
> это валидно, фигли. А реально - поэтому и придумали C99 с
> явно озвученным числом битов на тип, так куда пресказуемее.Ну, вообще говоря, если вы пишете программу под конкретное известное железо, то вы точно знаете его характеристики, следовательно — эта особенность С89 не является для вас проблемой. А если пишете её для нескольких разных архитектур, то, скорее всего, вы тоже точно знаете их свойства и умеете делать так, чтобы различия не стали проблемой. Си, как ни крути, ЯП не для дураков, а для профессионалов, чётко понимающих, что и как они делают.
> Ну, вообще говоря, если вы пишете программу под конкретное известное железо, то
> вы точно знаете его характеристики,Я вам тут не ассемблерщик (я прогал на нескольких асмах, но - надоело), и таки использую много довольно разного железа. И со своей стороны считаю портабельность сей весьма и весьма жирным плюсом. По поводу чего предпочитаю скорее C99. Порой несколько уменьшенный subset - для МК.
> следовательно — эта особенность С89 не является для вас проблемой.
Мне виднее и мои приоритеты и что является для меня проблемой. Поэтому для себя я решил оперировать C99 (без VLA, кроме случая когда есть очень крутая причина и это не мешает иным вещам). Ну и posix как апи если это еще к оси интерфейсить надо. И писать максимально портабельно при условии что это ничего не нагибает.
А хотя-бы потому что например удобно на стороне компа какой-нибудь алгоритм или кус логики прозвонить, в том числе под мощными тулсами типа asan/ubsan до того как его на мк допустим пускать.
На микроконтроле ... пакость типа avr вообще будет как яваскрипт, всепофиг, продолжаем работать, хоть там чо. Cortex, конечно, hardfault пульнет но понять от чего он вылез в урезанном окружении - канительнее и неудобнее. Справедливости ради, мне приходится вручную левый доступ к памяти делать чтобы вообще проверить что handler срабатывает, но все-же.
> делать так, чтобы различия не стали проблемой. Си, как ни крути,
> ЯП не для дураков, а для профессионалов, чётко понимающих, что и как они делают.Ну и с этой точки зрения - если я знаю что вон те данные будут 32 бита, мне логично и заказать им uint32_t, а не какой-то абстрактный int с риском поиметь грабли если на какой-то платформе int окажется вдруг не столько.
Если так заметить, именно профессионалы тоже эти типы не лю и часто делают typedef с более вменяемыми типами и кучей кослылепроверок ifdef/sizeof. Мне так поганить код впадлу и я просто юзаю C99.
> Хочешь расскажу где лежат исходники CPython 2.2, например? Вот прикинь, если
> тебе кровьизносу надо конкретную версию интерпретатора - я тебе разрешаю взять
> и использовать ее.Зачем мне это? После пары жирных обломов жизнь научила меня что закладываться на продукты жизнедеятельности вбемакак - чревато.
> Так можно! Без разрешения Папы Римского! Не упустите свой шанс!
Блин, а ты можешь собачье г@вно с тротуара убрать. Впрочем за гвидо убирать хуже, во всяком случае ему даже лавры BDFL-я уже не по кайфу, сбежал даже так.
> Зачем мне это?А мне почем знать зачем ты плакался по поддержке старых версий интерпретатора?
Ну наверное не для того чтобы за гвидо его факапы разгребать. Хотя если liquidation manager'ом позовут - я подумаю над этим...
> И таки да: проще переписать на другом языке, чем пытаться поддерживать что-либо на питоне.А не надо писать на Питоне вещи, которые стоит поддерживать. Это отличный инструмент для своей области, а вылезать из неё не стоит.
Кому мало можно посмотреть на историю "успеха" редхата, которые за наверное 20 лет так и не смогли сделать вменяемый пакетный менеджер, вместо этого тщетно пытаясь окультурить свой картонный макет. В результате этот картонный макет жрет море ресурсов, глючит, падает, унося за собой БД и потом система остается как после ядерного взрыва. Под бойкие рассуждения о транзакциях и прочей расовой верноте. Какие, к дьяволу, транзакции, когда пакетный менеджер встает в позу когда он ни бе, ни ме, ни кукареку?!
простите, но унести с собой БД он не может - у него ее нет.
Индексы репо - не бд и могут в любой момент быть сгенерены заново.А если у вас проблема с rpmdb - так угадайте, в какой несчастливый год и на каком вполне академичном языке толпа студентов решила переписать на гранты то ли орацла то ли не помню - до того - совершенно беспроблемный код? Приятно отметить, что ответочка прилетела грантодателю - в соплярисе у них, не поверите, те же проблемы ровно из того же источника ;-)
Выкинуть и переписать на sqlite - это не к редхатовцам, они двадцать лет боятся трогать даже обертку вокруг него. А если перепишут - сделают "как в орацле - орацле нашел способ обмазаться навозом - и мы найдем!"
> простите, но унести с собой БД он не может - у него ее нет.А почему при OOM усе улетает с жоским стэктрейсом и при следующих попытках что-либо делать оно вопит "database corrupt"? И дальше вообще ни вперед, ни назад.
При том это тупо единственный пакетный менеджер который я знаю который настолько жоска ломается и потом хренподымешь. Ну например в дебиане в такой ситуации как максимум надо еще раз запустить инсталл, пакетник даже команду подскажет.
> Индексы репо - не бд и могут в любой момент быть сгенерены заново.
При том изначально эти *МАКАКИ* напихали туда аж XML. Потом оказалось что это жирное и дико тормозит - давайте дескать будем скулайтные базы сгружать?! Еще один пример когда сперва сделали, потом подумали. Уровень инженерии в этой поделке так и прет из всех щелей.
Даже у какой-нибудь фрибзды на фоне этого позора пакетный менеджер лучше, хахаха.
> до того - совершенно беспроблемный код? Приятно отметить, что ответочка прилетела
> грантодателю - в соплярисе у них, не поверите, те же проблемы
> ровно из того же источника ;-)Уж не знаю когда оно там было совершенно беспроблемным. Во времена up2date чтоли?
> Выкинуть и переписать на sqlite -
Ну для начала - на си, чтоли. Почему-то это смогли даже фрибсдшники, лол. А, да, с скулайтом вроде. Типа кучка академбомжей может а редхат нет? :)
> А почему при OOM усе улетает с жоским стэктрейсома почему у тебя при установке пакетов - oom? У меня вот нет никаких oom, а если на системе творится чорти-что и сейчас кончится память - самое последнее что мне придет в голову, вместо чистки начать там еще что-то устанавливать.
> При том изначально эти *МАКАКИ* напихали туда аж XML.
что не так с xml в качестве структурированных данных? Конечно же yaml, как у freebsd, гораздо круче, и так занятно ломается об лишний невидимый символ?
> Даже у какой-нибудь фрибзды на фоне этого позора пакетный менеджер лучше, хахаха.
пакетный менеджер, не умеющий нормальных версий пакетов - конечно лучше, хахаха
> Ну для начала - на си, чтоли.
пишите. Полагаю, выйдет еще хуже и ненадежнее, а вполне вероятно - и медленнее.
Поскольку те операции, которые требуют затрат времени - они там и так на си (поскольку это rpmlib)
Где у FreeBSD yaml?
Вот пока не разберешься где - не лезь на опеннет, тут и без тебя альтернативно-одаренных хватает.
Настоящий бсдшник пользуется исключительно виндой. Поэтому извольте объясниться.
ааа, блин, действительно, откуда им знать.manifests = "packagesite.yaml";
filesite = "filesite.yaml";
> Настоящий бсдшник пользуется исключительно виндой.А линухоиды, судя по комментариям в соседних новостях, предпочитают мак?
>> При том изначально эти *МАКАКИ* напихали туда аж XML.
> что не так с xml в качестве структурированных данных? Конечно же yaml,
> как у freebsd, гораздо круче, и так занятно ломается об лишний
> невидимый символ?Наверное тем, что _автоматически генерируемые_ списки и описания в yaml, в случае нужды, человекочитаемее? И лезть туда с нотпадом что-то править обычно совсем не нужно.
> Наверное тем, что _автоматически генерируемые_ списки и описания в yaml, в случае
> нужды, человекочитаемее? И лезть туда с нотпадом что-то править обычно совсемвы уж определитесь, мущина - туда либо сюда? Если вам понадобилось их человекочитать - вы уже открыли их в нотпаде. Возможно, потому что лишний пробельчик-то уже просочился, и все паламалася? ;-)
Если бы было нужно только роботом парсить - было бы совершенно похрену, читаемы они или нет.
>> Наверное тем, что _автоматически генерируемые_ списки и описания в yaml, в случае
>> нужды, человекочитаемее? И лезть туда с нотпадом что-то править обычно совсем
> вы уж определитесь, мущина - туда либо сюда? Если вам понадобилось их
> человекочитать - вы уже открыли их в нотпаде. Возможно, потому что
> лишний пробельчик-то уже просочился, и все паламалася? ;-)Только после того, как вы раскроете тайну "просачивания" пробела в автоматически сгенерированный файл ;-)
Файл(ы), которые даже собирая свои собственные или сильно модифицированные пакеты для своей, локальной репы, можно годами ни разу не видеть и не открывать.
А то ведь читая вас можно подумать что приходится править YAML-манифесты нужно чуть ли не раз в полчаса.
И да:
{
"name": "qt5-network",
"origin": "net/qt5-network",
"version": "5.13.2",
"comment": "Qt network module",
"maintainer": "kde@FreeBSD.org",
"www": "https://www.qt.io/",
"abi": "FreeBSD:12:amd64",
"arch": "freebsd:12:x86:64",
"prefix": "/usr/local",
"sum": "14700af2b1d09fb9f49a9c14787f9e278ffbb77ef9b47c196c5c2006d046129c",
"flatsize": 2523395,
"path": "All/qt5-network-5.13.2.txz",
"repopath": "All/qt5-network-5.13.2.txz",
"licenselogic": "single",
"licenses": [
"LGPL21"
],
"pkgsize": 568828,
"desc": "Qt is a cross-platform application and UI framework for developers\nusing C++>
"deps": {
"ca_root_nss": {
"origin": "security/ca_root_nss",
"version": "3.48"
},
читается приятнее, чем нагромождения тегов, еще и неплохо обрабатывается при (гипотетической) надобности с помощью grep/awk/jq.
> надобности с помощью grep/awk/jq.Абсолютно. XML одинаково хреново парсится и человеками и машинами.
> сейчас кончится память - самое последнее что мне придет в голову,
> вместо чистки начать там еще что-то устанавливать.Как показали эксперименты, Дебиан в тех же конфигурациях ведет себя культурно. Мне что, покупать более дорогие виртуалки спецом под эпизодический запуск пакетного менеджера?
> что не так с xml в качестве структурированных данных?
Крайне избыточный по возможностям (e.g. XSLT). Это гарантирует что либа парсинга - жирный тормозной монстр, с кучей уязвимостей и стремным апи, решающим совсем не те задачи и лопающие RAM оптом. В результате софт который это использует обречен иметь все минусы энтерпрайзного г@вн@. А попробуй парсить XML на 50К пакетов, узнаешь почему шляпа в скулайт кешировать стала. Так то да, пока там 100 записей, и XML - "типа база".
> Конечно же yaml, как у freebsd, гораздо круче,
Vs XML? Masterpiece of engineering!
> и так занятно ломается об лишний невидимый символ?
Вообще наполовину фича - детектирует левые данные. Чего ради это вообще в *тексте* должно быть? Это либо факап майнтайнеров либо атака mitm-а. В любом случае это должно быть убрано в темпе вальса.
> пакетный менеджер, не умеющий нормальных версий пакетов - конечно лучше, хахаха
Это дело наживное. А питонокрап вместо пакетного менеджера у редхата уже чуть 20 лет, и воз и ныне там. С какими-то голимыми полумерами типа dnf. На фоне обычного дебиановского апта это просто трэш и ад.
> пишите. Полагаю, выйдет еще хуже и ненадежнее, а вполне вероятно - и медленнее.
У дебианщиков нормально получилось. И надежно и шустро. Без всяких многолетних тантрических экспериментов и полунедохакофиксов.
> Поскольку те операции, которые требуют затрат времени - они там и так на си (поскольку это rpmlib)
А по нему и не скажешь - тупил в разы сильнее apt'а. Что за порно они там с dnf сделали я не следил, ибо гумно вместо пакетного менеджера задолбало раньше. Я считаю что 1 раз за 20 лет пакетный менеджер можно и нормально написать, а не левой пяткой вебмккак.
> А почему при OOM усе улетает с жоским стэктрейсом и при следующих попытках что-либо делать оно вопит "database corrupt"? И дальше вообще ни вперед, ни назад.Недавно я по глупости запустил yum update из сеанса ssh, работающего через VPN. Совершенно случайно прилетело обновление VPN-демона... в общем, тоже "database corrupt". И дальше вообще ни вперед, ни назад.
Правда, через пару минут нашлась официальная инструкция от редхата, как перегенерировать базу данных. И — вы не поверите — волосы вновь стали мягкими и шелковистыми.
Да, я с редхатами имею дело редко. А вы, похоже, вообще с администрированием не связаны, раз искать информацию не умеете.
> И дальше вообще ни вперед, ни назад.Дарю идею: у дебиана нормальный пакетный менеджер. И следующие 5 лет с 10-м дебианом можно спать спокойно. А редхат... он имеет смысл если у вас подписка на саппорт, чтоли.
И, кстати, дебиану вообще и его пакетному менеджеру в частности нормалек даже на самом тощем vm с 128 оперативки. Без свопа. На минуточку, это ВЧЕТВЕРО меньше минимальных требований RHEL.
> мягкими и шелковистыми.
Ну его нафиг такой шелк...
> А вы, похоже, вообще с администрированием не связаны, раз искать информацию не умеете.
Я, по счастью, упомянутым маршрутом отправился - и теперь мне это просто неактуально. А чисто по человечески - вот на таких вещах и ощущаешь "сделано людьми, для людей" и "сделано индусами, на продажу". Блин, ну вот зачем мне софт выпиленый лобзиком индусами? Он мне такой даже бесплатно ни к чему - кошмарный слишком.
> И, кстати, дебиану вообще и его пакетному менеджеру в частности нормалек даже
> на самом тощем vm с 128 оперативки. Без свопа. На минуточку,
> это ВЧЕТВЕРО меньше минимальных требований RHEL.Только если раскатывать из образа каким-нибудь dd. Установить актуальный Debian штатным порядком на машину со 128 МБ ОЗУ сегодня уже не получится. А работать будет, да.
> Только если раскатывать из образа каким-нибудь dd. Установить актуальный Debian штатным
> порядком на машину со 128 МБ ОЗУ сегодня уже не получится.Ну как бы 128 у меня бывает только на виртуалках. И cp --reflink <template> <new_VM> неизмеримо быстрее чем час жевать сопли каким там еще дебиан-инсталлером.
А образ сделан обычным debootstrap'ом, где ничего лишнего. И я таки вижу разницу между затратами времени в секунду и в час. Это отличает меня от фанатов setup.exe :)
> А работать будет, да.
И работает. Хорошенько минимизированная VM даже и с 64 живет, по крайней мере "armhf". Но медленно, на кэш нифига не остается.
> Это отличный инструментПричём он отличный в каждой минорной версии.
> Причём он отличный в каждой минорной версии.Совершенно верно. И профессионал должен это знать, и не должен использовать инструмент не по назначению - "шуруп, забитый молотком, держится лучше гвоздя, закрученного отвёрткой".
>> Причём он отличный в каждой минорной версии.
> Совершенно верно. И профессионал должен это знать, и не должен использовать инструмент
> не по назначениюрасскажите же, о гуру - чем же назначение пихона 3.5 отличалось от назначения пихона 3.6 ?
Практически ни в чём. Ключевое тут - меняется от версии к версии. Очевидно, что если вы используете этот язык для долгоживущего продукта, проблемы обеспечены.
> Практически ни в чём. Ключевое тут - меняется от версии к версии.
> Очевидно, что если вы используете этот язык для долгоживущего продукта, проблемы
> обеспечены.в 2005м году, видимо, было еще далеко не очевидно.
Надо было быть не профессионалом-разработчиком, а профессионалом оккультных наук, чтобы предугадать "python3 это не новая версия, это другой йазык!", с последующим переобуванием в полете, и категорическим отказом от поддержки другого язы...простите, немодной мамонтово-кальной версии того же самого (причем с мутнейшей лицензией, не позволяющей никому занять вакантное место - см. пункт 7 последней версии).
Извините, но вся около-питоновская культура - это "менять и не бояться выбрасывать старое". Типичный пример optparse vs argparse - разницы между ними почти нет, а та, что есть, совершенно не перекрывает геморрой от миграции и тестирования. Ocaml, например, уже лет 30 живёт с модулем https://caml.inria.fr/pub/docs/manual-ocaml/libref/Arg.html (для желающих что-то серьёзнее есть другие модули, а этот не меняется и не устаревает).Я в 2005 за Питоном особенно не следил. Разве что видел, что строить на нём сложные GUI программы очень тяжело - они постоянно вылетали. Но я полагаю, что культура сообщества разработчиков тогда была примерно той же - "легко менять и легко выбрасывать старое".
А с таким вечно меняющимся фундаментом нельзя строить что-то долгосрочное:
"… пока противник рисует карты наступления, мы меняем ландшафты, причем в ручную. Когда приходит время атаки противник, теряется на незнакомой местности и проходит в полную не боеготовность. В этом смысл. В этом наша стратегия…"
> А с таким вечно меняющимся фундаментом нельзя строить что-то долгосрочное:* первый релиз NumPy - 2006
* первый релиз IPython - 2001
* matplotlib - 2003
* pandas - 2008
PS: Для справки, OCaml - это 1996 год.
Эти библиотеки просты как валенки, плюс туда вливаются совершенно сумасшедшие средства и силы. И, кстати, API этих библиотек тоже не сказать, что стабилен.А мы про Mercurial говорим, которому всё это вычматовское библиотечное до лампочки. Это совершенно разные области применения:
Data science, aka automated statistics - это штука, прекрасно ложащаяся в идеологию Питона: быстро напиши, получи результат и выбрось. Никаких проблем с поддержкой совместимости и т.д. Поэтому здесь он выступает на 5+. Ну поломали вы numpy, ну следующий notebook будете писать на новом API.
Mercurial - это жесточайшая обратная совместимость (за невозможность читать старые репозитарии сделают Матумбу), неограниченная жизнь кода, большие тексты с огромным количеством ветвлений.
> Эти библиотеки просты как валенкиЭм?!
> плюс туда вливаются совершенно сумасшедшие средства и силы.
Крестик или трусы?
> А мы про Mercurial говорим, которому всё это вычматовское библиотечное до лампочки.
Ну, во-первых, там не только "вычматовские". А во-вторых, вы писали
что "с таким вечно меняющимся фундаментом нельзя строить что-то долгосрочное" (ц)
Вот вам пожалуйста - таки можно. А то, что нет второго hg, ну так извиняйте,
и первый не слишком взлетел. Возможно это и связано с языком, а возможно дело
в танцорах. Потому что другим ни поддерживать Python 3 ни делать
долгосрочные проекты - язык, очевидно, никак не мешает.> Data science, aka automated statistics - это штука, прекрасно ложащаяся в идеологию
> Питона: быстро напиши, получи результат и выбрось. Никаких проблем с поддержкой
> совместимости и т.д. Поэтому здесь он выступает на 5+. Ну поломали
> вы numpy, ну следующий notebook будете писать на новом API.Data science - это модная фигня, не имеющая прямого отношения к собственно
science, помимо названия. А в той science, за которую Нобелевские премии
дают - к совместимости отношение куда более трепетное, поскольку "получить
результат" мало. Надо еще чтобы коллеги могли воспроизвести твое чудо.> Mercurial - это жесточайшая обратная совместимость (за невозможность читать старые репозитарии
> сделают Матумбу), неограниченная жизнь кода, большие тексты с огромным количеством ветвлений.Вы думаете, что .hdf5 можно читать каждый раз как-то "творчески"?
Поддерживаю по каждому пункту, Vkni (увы, модеры не могут ставить плюсики, так что приходится писать комментарии одобрения).Хочу также заметить, что диалог с мыхандом есть монолог, но всё равно желаю Вам успехов! =)
> Поддерживаю по каждому пункту, VkniТ.е. вы тоже считаете, что на питоне нельзя строить что-либо
долгосрочное, несмотря на кучу предъявленных примеров обратного?
(Чу, или мне показалось как некто хвалился тем, что умеет
слышать аргументы оппонента?)> модеры не могут ставить плюсики
Божечки, да школиe с хабра за вас уж натренировано - расставят
все как надо, контроль плюсометной моторики у них уже натренирован,
до головного мозгу дело не доходит...PS: Модеры зато могут удалять то что им не понравится по желанию левой пятки.
> Т.е. вы тоже считаете, что на питоне нельзя строить что-либо
> долгосрочное, несмотря на кучу предъявленных примеров обратного?Можно, но это потребует значительно больших вложений сил. Всё это тьюринг-полные языки, то есть, в достаточно широких рамках их в принципе можно заменить друг на друга.
Вопрос же в том, сколько сил придётся вложить в поддержку и разработку.
>> Т.е. вы тоже считаете, что на питоне нельзя строить что-либо
>> долгосрочное, несмотря на кучу предъявленных примеров обратного?
> Можно, но это потребует значительно больших вложений сил.Отлично. Флаг вам в руки: объясняйте почему есть куча проектов,
не ленящихся использовать питон, несмотря на необходимость энтих "сил",
а на OCaml есть в лучшем случае один Coq (и у меня, скажем так, есть
серьезные подозрения почему он на нем есть).
> Отлично. Флаг вам в руки: объясняйте почему есть куча проектов,
> не ленящихся использовать питон, несмотря на необходимость энтих "сил",Потому что в ряде случаев субъект, выбирающий язык, ориентируется на что-то внешнее:
1. Лёгкость набора кодеров под язык.
2. Зарплату кодеров.
3. Моду.
4. Уже имеющуюся экосистему.
> а на OCaml есть в лучшем случае один Coq
Это не так - есть та же Jane Street, вполне себе пилящая всякое своё.
>> Отлично. Флаг вам в руки: объясняйте почему есть куча проектов,
>> не ленящихся использовать питон, несмотря на необходимость энтих "сил",
> Потому что в ряде случаев субъект, выбирающий язык, ориентируется на что-то внешнее:Ну что вы, кроме пользователей OCaml ведь все - мазохисты...
> 1. Лёгкость набора кодеров под язык.
А вот это как раз разумное требование. Особенно если учитывать, что (сюрприз,
сюрприз!) значительная доля ПО создается прикладниками, а вовсе не программистами.>> а на OCaml есть в лучшем случае один Coq
> Это не так - есть та же Jane Street, вполне себе пилящая всякое своё.Да нет, пожалуй это ровно один значимый FOSS проект на OCaml. Еще что-то есть,
но это разная фигня вроде p2p клиентов (mldonkey?).
> модеры не могут ставить плюсикиУ меня давно сложилось впечатление, что +- ставят боты или люди с примерно той же программой поведения, поэтому я их игнорирую.
Если комментарий многабукав, причем сильно заминусованный или (реже) наоборот - стоит приглядеться.
>> модеры не могут ставить плюсики
> У меня давно сложилось впечатление, что +- ставят боты или люди с
> примерно той же программой поведения, поэтому я их игнорирую.Имхо, +- есть в некотором смысле показатель солидарности со мнением. Чем писать 100 комментов вида "поддерживаю", "согласен", и т.п. -- куда разумнее воспользоваться системой рейтинга.
Разумеется, рейтинг нужен не для тебя или меня. Рейтинг есть направляющая для новопришедших, которые ещё не знают, как тут ориентироваться, что хорошо, что плохо. И наш рейтинг вроде бы корректно пока отражает действительность, в отличие от, скажем, хабрахабровского.
Ну странный какой-то показатель. Вот у меня в практически всех комментах здесь мысль одна - "язык, это инструмент, который надо применять в соответствующей области". И почему-то один из этих комментов имеет -15, а остальные - что-то в районе нуля. Хотя какая разница?
> Data science, aka automated statistics - это штука, прекрасно ложащаяся в идеологию
> Питона: быстро напиши, получи результат и выбрось.Ну так откуда-то оттуда змий и полез. И вот там это и правда никому не создает проблем - половина такого софта вполне себе одноразовый лабораторный макет. Никому же не приходит в бошку требовать от лабораторной установки гламурный корпус и хороший юзеринтерфейс, те кто с ней возятся и так разберутся.
> И вот там это и правда никому не создает проблем - половина такого софта вполне себе одноразовый лабораторный макет.Более того, там это очень полезно. Например, текст в значительной части Wolfram Notebook или Jupyter Notebook совершенно не обязан быть корректной программой (там могут быть какие-то обрезки кода, сложенные внизу впрок). При этом система, которая будет настаивать на обязательной компилируемости этого Notebook, будет только мешать (это я как опытный пользователь пишу).
> Надо было быть не профессионалом-разработчиком, а профессионалом оккультных наук, чтобы
> предугадать "python3 это не новая версия, это другой йазык!"А чего, с прохвессионалов-разработчиков не требуют более навыков чтения? Эта страшная
тайна ведь была в whatsnew написана прям тогда.
вот лохи и повелись.А оно херак, и в полете - переобулось. Оказывается все таки не новый язык, а новая версия интерпретатора, а "этот ваш мамонтовый кал" - нинунанинуна.
И registered trademark вишенкой на тортике, чтобы те кому нужно для тех кому нужно - все равно не сумели сделать надежно.
> А оно херак, и в полете - переобулось. Оказывается все таки не
> новый язык, а новая версия интерпретатораthe first ever intentionally backwards incompatible Python release
Мне делается страшно за ваше здоровье от наблюдений за тем как вы ковыряетесь в носу. Пожалуйста, перестаньте.
Interviewed Friday morning, foundation representative David Goodger said "We fixed problems so we can go forward and add features more easily in the future without having to work around previous bad decisions."A transitional release toward the 3.0 platform, Python 2.6, was released in October and updated with bug fixes in Python 2.6.1 this week. A Python 2.7 release also is planned, and the foundation anticipates most people will stick with the Python 2 line for years, Goodger said.
что вас удивляет в том, что лохи и повелись?
> А оно херак, и в полете - переобулось. Оказывается все таки не
> новый язык, а новая версия интерпретатора, а "этот ваш мамонтовый кал"
> - нинунанинуна.А библиотеки вы вообще не учитываете? Основная проблема же в том, что библиотеки меняются.
>> Это отличный инструмент
> Причём он отличный в каждой минорной версии.Ты сделал мой день, Led! Аж слеза навернулась! =)
>>> Это отличный инструмент
>> Причём он отличный в каждой минорной версии.
> Ты сделал мой день, Led! Аж слеза навернулась! =)Редчайший случай, когда он написал что-то умное, а не просто наследил в комментариях.
> Редчайший случай, когда он написал что-то умное, а не просто наследил в комментариях.Пожалуйста, ребята, не ссорьтесь. =)
> посмотрите на то, в каком состоянии "готовности" находятся стандартные библиотеки.Посмотрите на гражданина, до сих пор не умеющего в читать документацию.
> За тридцать-то лет языка они, небось, должны быть совсем в ином состоянии.
Прям можно подумать, что у какого-то языка есть сравнимая по функционалу стандартная библиотека.
Собственно, в количестве батареек и находится большая часть проблемы. Оно вот это
все действительно нужно там? Вроде потихоньку начинают выковыривать.> И таки да: проще переписать на другом языке, чем пытаться поддерживать что-либо на питоне.
Вы просто не писали нечего дальше скриптиков на 1kLOC.
> Посмотрите на гражданина, до сих пор не умеющего в читать документацию.А еще этот негодяй наверное миноискатель дома забыл, так что если ему кто на пути растяжку расставил - это не он м...к, а гражданин - растяпа. Хорошая логика, жаль что опасная для жизни и здоровья.
Хорошая документация - это растяжка?
> Хорошая документация - это растяжка?Если в нее после каждой минорной версии вштыривать надо - пожалуй что да.
В последнее время, Python че-то не туда шагнул. То все эти асинхронные фишки скоммунизженны с Node.js, чтобы быть не хуже, но при этом со своими узелками в кишках; то какое-то местами усложнённое г в синтаксисе простого языка. Всё это вызывает грусть и тоску, вместо выпиливания GIL и впиливания JIT занимаются откровенной мало кому нужной ерундой, все эти «Foundation» - кормят не пойми кого
> В последнее время, Python че-то не туда шагнул.Место BDFL всё ещё вакантно! Не упусти свой шанс решать, куда шагать python'у
> То все эти асинхронные фишки скоммунизженны с Node.js
Видите ли, эти "асинхронные фишки" дают дикий буст производительности IO-задач. Кстати (могу оказаться неправ), синтаксис async/await вообще в шарпах появился. Кто откуда комуниздит?
> выпиливания GIL
А мужики то и не знали, что реализация IronPython без GIL!
Вообще с GIL не так всё просто. Это инженерное решение со своими достоинствами (внезапно оно производительно) и недостатками (заставляет отбросить многопоточность, когда дело касается производительности. Впрочем, когда дело касается производительности, самое время подумать о сишном расширении)> впиливания JIT
Смотри: https://github.com/gvanrossum?tab=repositories
В списке есть mypy. Чем занимается mypy? Слышал ли ты о cython? Чем принципиально cython отличается от python? А теперь снова посмотри на mypy.
Субъективно моё предположение -- вывод типов -- первый шаг к JIT
> Вообще с GIL не так всё просто. Это инженерное решение со своими достоинствами (внезапно оно производительно) и недостатками (заставляет отбросить многопоточность, когда дело касается производительности. Впрочем, когда дело касается производительности, самое время подумать о сишном расширении)Зря ты это затеял — объяснять не-программистам всякие технические кишки. Они ж верят, что если напихать как можно больше тредов, то абсолютно любая задача будет решаться за кратно меньшее время.
Что такое конкурентность, как она связана с асинхронностью и чем это отличается от параллельности — это всё равно что в детском саду читать лекции по квантовой физике.
Бро, каникулы скоро закончатся, и можно будет спокойно продолжать о технических нюансах :)
Зелен виноград.
> Место BDFL всё ещё вакантно! Не упусти свой шанс решать, куда шагать python'уСрочно разыскиватеся диктатор с мазохистичными наклонностями! А, погодите, может это liquidation manager так называется? :)
> Видите ли, эти "асинхронные фишки" дают дикий буст производительности IO-задач.
Видите ли, кого это колыхало давно пишут на каком-нибудь go, чтоли. Там еще и код нативный, что дает дикий буст по всей площади кода.
> Кто откуда комуниздит?
Все друг у друга понемногу.
> А мужики то и не знали, что реализация IronPython без GIL!
А этой жестью :) кто-то пользуется вообще?
> Вообще с GIL не так всё просто. Это инженерное решение со своими
> достоинствами (внезапно оно производительно) и недостатками (заставляет отбросить многопоточность,Взаимоисключающие параграфы как они есть.
Посмотрим на Go2. Как бы они пытаются сломать как можно меньше, но проблема в том, что это Google.
> Посмотрим на Go2. Как бы они пытаются сломать как можно меньше, но
> проблема в том, что это Google.Хипстерам вообще полезны иногда отрезвляющие клизмы с патефонными иголками ;]
А где же тот чувачок, который "...несовместимая 3-я версия это лучшее что случилось с питоном"? https://www.opennet.dev/openforum/vsluhforumID3/119416.html#30
А разве обсуждаемая новость как-то опровергает его слова?
Я бы им посоветовал переписать всё на стабильном языке — на Перле, например.
На COBOL 60. Куда уж стабильнее!
> На COBOL 60. Куда уж стабильнее!Если бы ты понимал, зачем был создан КОБОЛ и почему он такой, тебе бы не казалась смешной глупость, которую ты написал.
И для чего же, по вашему мнению? Неужели для написания DVCS? :)К COBOL-у как таковому у меня никаких претензий, в свое время отлично решал свою задачу.
Люто плюсую! Желать что-то долговечное на Пистоне моветон.
> Люто плюсую! Желать что-то долговечное на Пистоне моветон.Вот люди и взорвались на мине замедленного действия.
>так как тесты не охватывают 100% кодовой базыССЗБ.
>Прогнозы о стабильности порта для Python 3 даются неутешительные. В частности, предполагается, что на протяжении нескольких лет в коде будут всплывать случайные ошибкиДержать годами техдолг - сами виноваты.
Перешли бы раньше - отладили бы раньше. Я вообще в 13 взял и перешёл. И 2 тут же дропнул. И мне сpать было на тех ретроградов, кто продолжал сидеть на 2. С 4 сделаю так же. Как только numpy + scipy + sklearn + tensorflow портируют, так сразу перйду на 4 и дропну 3 во всех своих либах. А ретрограды пусть дальше ноют и прокрастинируют, лишь бы не работать.
Какие смузи пьёшь? Обтягивающие джинсы кровоток перекрывают? Нравится все ново-молодёжное?
Если я правильно понял, он сказал, что сидел на тупиковом овне мамонта 5 лет (что в общем-то дохрена) и был очень рад, когда его скинул (необходимость поддерживать 2 ветки одновременно очень сковывает и заставляет делать много бесполезной работы). И я рад за него.Но хотя я сравнивал 36,34 и 27, так 36 потреблял больше всего памяти и был самым медленным. Вероятно не в последнюю очередь из-за того, что код был в стиле 2 питона.
На самом деле я на 2 вообще не сидел. Я просто в 2013 начал на питоне кодить, так что все мои либы изначально шли с трёшки. Просто двойка была ещё почему-то очень популярна, так что в наглую забить на неё мало кто был готов. А посыл в том, что ещё в 13 питон 3 был абсолютно полностью юзабельным. Со всеми sklearn, numpy и scipy. Если какая-то либа не была портирована - я просто делал 2to3. В большинстве случаев вообще ручных фиксов не требовалось. Даже если и требовалось, то обычно не более 3 строк на всю либу, хотя бывало требовалось пофиксить и 20. То что его не дропнули сильно раньше 20 - это просто толерантность к тунеядцам, предпочитающим копить долг, а потом ныть про баги и валить всё на злых разрабов, которые копить долг не захотели.
> Обтягивающие джинсы кровоток перекрывают?Да что там, кеды жмут :)
Тогда надо на гном переходить :)
пью джинсы с подваротами! смузи кровоток не перекрывают! все норм чтяднт?!
> А ретрограды пусть дальше кодят что-нибудь полезное и новое вместо вечного реF*CKторинга...Пофиксил.
> ретрограды
> полезноеПоделил на ноль.
> Поделил на ноль.Ну, э, блин, если инноваторы тебе фирмвару твоему гироскутеру на пихоне накатают - ты таки обольешься смузи и расшибешь табло об асфальт.
>Ценой перевода Mercurial на Python 3
>может стать шлейф непредвиденных ошибок- Может?! Да они оптимисты, впрочем, никогда не было и вот опять!
Я не питонист, но неужели эти языки (питон 2 и питон 3) ведут себя настолько по-разному?
> Я не питонист, но неужели эти языки (питон 2 и питон 3)
> ведут себя настолько по-разному?Более того - взяв произвольный скрипт на допустим 2.4 на более актуальном сейчас 2.7 это скорее всего либо не заработает, либо грохнется с ошибкой в середине работы. Примерно тот же тренд если взять скрипт писанный на каком-нибудь 3.4 и попытаться его на 3.6 вкорячить.
Кстати майкрософт так тоже пробовал. К 4.5-й версии дотнета с него сбежали даже самые стойкие. Потому что все время конопатить свой код и ловить предъявы от клиентов за жирные баги на ровном месте - утомительно.
> Более того - взяв произвольный скрипт на допустим 2.4 на более актуальном сейчас 2.7 это скорее
> всего либо не заработаетвообще-то ровно наоборот - это - скорее всего заработает.
Не заработает 2.7 код на 2.4, если только не написан очень специальным образом (вот в частности merurial - если бы не вынужден был гнаться за вечно уходящим паровозом, обрастая костылями совместимости с десятком третьих ненужноверсий - работал бы по сей день).
> вообще-то ровно наоборот - это - скорее всего заработает.Мой опыт ровно обратный.
> Не заработает 2.7 код на 2.4, если только не написан очень специальным образом
Ну это уже какая-то экзотика, обычно в системе версии софта вверх подтягивают по ходу пьесы. И в этот момент обнаруживается что почему-то куча скриптов перестала работать. F..K THAT.
> (вот в частности merurial - если бы не вынужден был гнаться за вечно уходящим паровозом,
> обрастая костылями совместимости с десятком третьих ненужноверсий - работал бы по сей день).Мне кажется что без расширений и совместимости народ еще быстрее свалил бы на гит...
По .Net прусы будет?
> По .Net прусы будет?Лично видел как при выпуске очередного дотнета померла шикарная жирная энтерпрайзная программа. То что саппорт компании мигом встал на уши даже и упоминать неудобно. А питонисты вообще развлекаются таким вбросом гранат в обезьянник каждые пару месяцев.
А на следующее утро отошел, и понял, что алкоголь не стояло мешать с грибами, а то жирные энтерпразные программы всю ночь чудятся
> А на следующее утро отошел, и понял, что алкоголь не стояло мешать
> с грибами, а то жирные энтерпразные программы всю ночь чудятсяНе алкоголь а кофе, и не я а прогеры и сапорты, очешуевшие пахать сверхурочно.
читай оригинал новости (надеюсь, нипихианист может в английский?)Да, настолько по-разному и намеренно ломая код в его самых базовых вещах.
> Я не питонист, но неужели эти языки (питон 2 и питон 3)
> ведут себя настолько по-разному?Буква «B» в слове «Python» означает «Backward compatibility»*.
Кстати, где эта буква в слове "C"?
В книжке K&R. ;)
Тогда для питона — ищите её в Dive into Python.
> Тогда для питона — ищите её в Dive into Python.Что же там пишут про обратную совместимость, аноним? Почему релизы третьей ветки между собой недостаточно совместимы?
Можно пример?
print 3/2Сойдёт за пример?
SyntaxError: Missing parentheses in call to 'print'. Did you mean print(3/2)?Может у вас какой-то специально обученный python3?
у него - 3.5, где так - было еще можно, хотя уже нельзя.
Пишут что проще утонуть
Уже весь мир перешел на python3, а быдлокодеры из меркуриал продолжают всем доказывать, что он не нужен. Уже и всю пользовательскую базу растеряли, уже и из дистрибутивов думают его удалить, а они все доказывают. Нет бы по человечески постепенно перейти когда вышла тройка -- это не для джедаев. Десять лет доказывать, что НИНУЖНА, а когда закончится срок поддержки сломя жопу плодя ошибки ускоренно мигрировать -- это по нашему.
ты-то не быдлокодер, ты бы за пять минут все переписал? А, не, ты вообще не умеешь кодить? Мы так и думали.Десять лет они никому ничего не доказывали, а развивали проект. Предполагая, что пользователю (не умеющему, кстати, кодить) вообще должно быть все равно на каком языке написано то, что он не собирается исправлять.
А вот если код будет просто сломан, и требовать установки самой наираспоследней версии нескучного язычка - то им пользоваться, внезапно, расхотят.
> ты бы за пять минут все переписал?Я же не из меркуриал-тим, чтобы переписывать за пять минут, у меня на это было бы 10 лет минимум.
> Предполагая, что пользователю (не умеющему, кстати, кодить)
Алло, это система контроля версий, 999 пользователей из 1000 -- программисты.
> Предполагая, что пользователю (не умеющему, кстати, кодить)
И что, конкретно, у них было в голове в этот момент? Что, по их мнению, должно было произойти? 2.7 жила бы вечно? Люди, отвечающие за 2.7 четко сказали когда кончится поддержка. Все живые проекты массово мигрировали на тройку. Очевидно, что в дистрибутивах не будут держать неподдерживаемый 2.7 ради меркуриала с 10 пользователями. Все это было не очевидно для разработчиков меркуриал, а дурак, почему-то, я.
> Я же не из меркуриал-тим, чтобы переписывать за пять минут, у меня на это было бы 10 лет минимум.у тебя на это была бы - вечность, каждый год - снова с нуля переписывать.
А работающего меркуриала при этом бы - не было. Одни переписывания.
> Алло, это система контроля версий, 999 пользователей из 1000 -- программисты.
ну ты вот не умеешь - а из тех 999 - 990 - таких же как ты. Остальные 10 - не программисты.
> И что, конкретно, у них было в голове в этот момент?
mercurial почти не спонсируется корпорациями (пользуются, но считают что делают одолжение). Полагаю, в этот момент, как и в текущий, у них в голове было ровно одно - людям не гонящимся за жупелами нового-молодежного - нужна vcs, а не переписывание ее на новом модном язычке.
У тех кому задрав штаны за стадом - уже есть распрекрасный гитшлак.> Очевидно, что в дистрибутивах не будут держать неподдерживаемый 2.7 ради меркуриала с 10
> пользователями.очевидно это проблема дистрибутивов и их отношения к пользователям.
Впрочем, пользователь меркуриала, скорее всего, сумеет поставить его без их помощи.
> Я же не из меркуриал-тим, чтобы переписывать за пять минут, у меня
> на это было бы 10 лет минимум.- Эй, чуваки, у нас тут корабль тонет! Все к насосам!!!
- Я вам тут не матрос воду качать!!!
Скорее "Врагу не сдаётся наш гордый Варяг, пощады никто не желает!"
>> Предполагая, что пользователю (не умеющему, кстати, кодить)Одному мне кажется, что подавляющему количеству пользователей Mercurial неумение кодить - это скорее сильно "некстати"?
Им пох. Нам вот с результатами их неумения жить приходится - это да, некстати. Но других разработчиков давно нет, а эти хоть из продвинутых - не только про волшебный git слышали (в котором умеют аж две команды...хотя нет, зачем - ведь есть "встроенный редактор")
Нужно было похоронить проект python 2 и переименновать его во что то другое при переводе проекта на python 3, например "Пистон 1.0" и представить публике как новый молодежный язык, тогда бы нытья по миграции с одной ветки на другую не было, так как некому было бы предъявлять претензиии, это был бы умирающий язык (пайтон 2), а умирающему претензии не шлют и ретрограды зачесались бы раньше по переводу кодовой базы на "Пистон 1.0" или выбрали любой другой на то время ЯП, а так они находились в фрустрации, надеялись на что то и болезнь растянулась на годы и приняла катастрофические последствия.Вообщем горе бизнесмены, маркетологи нешмагли или их не было в команде на то время рубануть с плеча и сменить имя проекту так, чтобы многие не догадались, что это решение команды пайтон 2 ))
они так и сделали.Но "умирающий язык" - это язык на котором не ведут и не поддерживают разработки. А вовсе не язык версии #-1. Который будет не "умирающим", а просто брошенным разработчиками.
Таких языков, которые просто умерли со временем - было. perl4, php<=4. Но умерли они от того, что на них просто не успели и не сумели ничего существенного написать, а не от того что гордый разработчик, поковыряв пальцем в грязном носу, заявил что "нипаддерживаеццца".
(поэтому с "нипаддерживаетца" php5 мы будем еще лет двадцать обниматься)
> Таких языков, которые просто умерли со временем - было. perl4, php<=4. Но
> умерли они от того, что на них просто не успели и
> не сумели ничего существенного написать, а не от того что гордый
> разработчик, поковыряв пальцем в грязном носу, заявил что "нипаддерживаеццца".
> (поэтому с "нипаддерживаетца" php5 мы будем еще лет двадцать обниматься)На PHP 4 вообще-то очень много чего успели понаписать, от форумных движков до phpMyAdmin, и моё отношение к большей части этого кода не отменяет значимости явления. Другое дело, что некая критическая масса разработчиков побежала за появившимся в PHP5 как бы ООП, благодаря чему нашлось немало желающих помочь с переездом.
>многие проблемы незаметны при статическом анализе и проявляются только во время выполненияВесь Питон в этой фразе. В нём без дебагера дальше хелоуворда не уйти.
Проект опенсорсный ? бесплатный ? программистам не заплатили за него ?
И вот чем это обернулось. Только экономическая модель жизнеспособна, только оплаченный труд принесет результат и не создаст проблем в будущем.
Все-таки без денег никуда, сейчас, если бы бизнесмены увидели экономическую выгоду от портирования, если бы после портирования был бы спрос на новый продукт - его можно было бы просто с нуля написать, наняв опытных и грамотных программистов, а деньги потраченные на оплату труда программистов, и возможно на рекламу окупились бы с продажи лицензий.
Но...мы ж любим опенсорс, всю работу сейчас придется делать людям бесплатно, или оставить как есть, но видимо оставить как есть - не вариант, потом что движуха уже началась :)
Даже какой-нибудь дропбокс, который таки мог оплачивать программистов, с питона таки ушел. Потому что проблем с ним все-таки много.
"потому что проблем с ними все-таки много."
Поправил вашу малозаметную опечатку, не благодарите.Разумеется, зачем их оплачивать, программистов-то. Халява ж везде!
>> только оплаченный труд принесет результат и не создаст проблем в будущемКхм, мне чота кажется, что оплаченность труда слабо коррелирует с наличием проблем в будущем...
> Проект опенсорсный ? бесплатный ? программистам не заплатили за него ?
> И вот чем это обернулось. Только экономическая модель жизнеспособна, только оплаченный труд принесет результат и не создаст проблем в будущем.Просто у них не было передовой партии.
Всё-таки не зря я года 4 назад перешёл на git. Правда осталось репов 8 на hg... Надо думать как их конвертировать. Но даже если и потеряю их историю версий, ничего такого страшного не произойдёт.
Спасибо Mercurial за простое погружение в мир распределённых систем контроля версий, но нет. Я пожалуй буду пользоваться git.
> разработчиков вынуждали переписывать код и тратить ресурсы на поддержание отдельных веток для Python 2 и Python 3Никто их не вынуждал поддерживать Python 2. Я все свои проекты перевел на 3 и все новые начинал уже только на нём, испытывая при этом только положительные эмоции.
> Лишь через семь лет ... были реализованы возможности, позволявшие ... обеспечить работу одной кодовой базы с Python 2 и Python 3
Ну понятно откуда ноги растут у всех их проблем. Мыши плакали, кололись, всё как обычно.
Я так к нескольким проектам (тому же deluge) слал патчи и предложения как переписать на Python 3, и все их ответы сводились к "ой, а нам это не нужно, а зачем, и так сойдёт". Ну ясно, понятно, хорошим им там и дальше настроения у себя в могиле.
И твои "проекты" конечно сравнимы с меркуриалом по сложности и значимости.
В мире, где полностью победил git, любой студенческий hello world сравним с Mercurial по значимости.
> В мире, где полностью победил git, любой студенческий hello world сравним с
> Mercurial по значимости.главное - верь, студент!
Что все эти меркуриалы и прочие ненужные тебе поделки имеют такую же значимость, как и выброшенный тобой сданный курсовик.
> Что все эти меркуриалы и прочие ненужные тебе поделки имеют такую же
> значимость, как и выброшенный тобой сданный курсовик.Учитывая что сабж выкинула даже битовая мусорка - он походу прав.
Важен процесс. Процесса не было
Надо было писать на Java.
Кому-то надо ещё объяснять, что динамические языки и пестон в часности - г***но?! ЯЗЫК НА ОТСТУПАХ, это ж надо придумать! Нехватает только Фортрана с его "6-ой позицией".
> Кому-то надо ещё объяснять, что динамические языки и пестон в часности -
> г***но?! ЯЗЫК НА ОТСТУПАХ, это ж надо придумать! Нехватает только Фортрана
> с его "6-ой позицией".Проблемность пихтона заключается отнюдь не в отступах.
А в Фортране (77) отступы, на мой взгляд, прекрасны и достойны восхищения.
Что-то не видел я там такого рояля (удовольствия соблюдать отступы фортрана (в ту пору прекрасную)).
> Что-то не видел я там такого рояля (удовольствия соблюдать отступы фортрана (в
> ту пору прекрасную)).Они структурируют программу и являются неотъемлемой частью её логики, всегда видной программисту. Сейчас таким занимаются IDE (иногда хорошо, иногда плохо), пожирая уйму ресурсов, а в Фортране встроено прямо в синтаксис языка. По-моему, очень умно и круто придумано. Да, я знаю, что это из-за и ради перфокарт — но и сами же перфокарты были и остаются крутейшим изобретением, которое невозможно переоценить.
> перфокарт — но и сами же перфокарты были и остаются крутейшим изобретением, которое
> невозможно переоценить.чтоб тебе колоду непронумерованных рассыпать на лестнице!
P.S. по йолкам их развешивать, правда, было здорово
>> перфокарт — но и сами же перфокарты были и остаются крутейшим изобретением, которое
>> невозможно переоценить.
> чтоб тебе колоду непронумерованных рассыпать на лестнице!А нефиг носить голые перфокарты по лестнице! Потом этими же руками ешь. В тележку сложи и — по направляющим для инвалидов…
> P.S. по йолкам их развешивать, правда, было здоровоИ плётки для БДСМ плести.
> А нефиг носить голые перфокарты по лестнице! Потом этими же руками ешь.
> В тележку сложи и — по направляющим для инвалидов…тогда не было направляющих для инвалидов.
Вы, похоже, таки опоздали родиться. Проклятье времен перфораторов было весьма и весьма серьезным - рассыпанная колода с чем-то нетривиальным это п-ц, несколько часов времени на вручную отсортировать, если что-то улетело в подвал или вылетело в окошко - стой в очереди к девочкам на перфораторе (этих шибкоумных-программиздов в крупных ВЦ старались самих не подпускать даже к перфоратору - сломают, как работать-то), но это все еще мелочи по сравнению с тем, что наверняка все равно где-то ошибся-не-заметил недостачи карточки и это выяснится уже в машинное время, а оно расписано по минутам и лишнего - нет, даже в выходные.
И это еще без бонусов в виде "лента в перфораторе не менялась десять лет/разложилась и выкинута, новых завхоз не покупает". Умеете ЕСовские перфокарты глазами читать?
Умные, конечно, надписывали номерки фломастером, но не все такие умные родились.
В общем-то, все были счастливы, когда стали сравнительно доступны магнитные ленты, пусть и читавшиеся местами и временами.
>> P.S. по йолкам их развешивать, правда, было здорово
и это вы тоже не поняли?
> В общем-то, все были счастливы, когда стали сравнительно доступны магнитные ленты, пусть
> и читавшиеся местами и временами.И что интересно, Хэмминг и ко - небось подревнее вас будут.
>> А нефиг носить голые перфокарты по лестнице! Потом этими же руками ешь.
>> В тележку сложи и — по направляющим для инвалидов…
> тогда не было направляющих для инвалидов.Тебе бы отдыхать от опеннета, пох, ты уже в простой человеческий юмор не врубаешься.
>[оверквотинг удален]
> это выяснится уже в машинное время, а оно расписано по минутам
> и лишнего - нет, даже в выходные.
> И это еще без бонусов в виде "лента в перфораторе не менялась
> десять лет/разложилась и выкинута, новых завхоз не покупает". Умеете ЕСовские перфокарты
> глазами читать?
> Умные, конечно, надписывали номерки фломастером, но не все такие умные родились.
> В общем-то, все были счастливы, когда стали сравнительно доступны магнитные ленты, пусть
> и читавшиеся местами и временами.
>>> P.S. по йолкам их развешивать, правда, было здорово
> и это вы тоже не поняли?Отдыхай, говорю, заработался ты написанием комментариев.
шестая позиция не имела в фортране семантического смысла - только синтаксический (то есть код начавшийся раньше восьмой, кстати - это tab - просто не компилировался), да и тот исключительно из-за особенностей техники тех времен.Если ты считал что от лишнего пробела код станет удобочитаемей - он от этого ничуть не портился.
Когда отпала необходимость в символе C - фортраны прекрасно перестали придираться к начальному отступу, он не влиял вообще ни на что.
Между прочим, библиотеки на 77-м (и даже более ранних) Фортране компилируются до сих пор. В нынешних версиях fixed-form необязателен уже лет 30, т.к. потерял смысл, а язык естественным образом развивается, принимая новые возможности. Просто есть вечное, а есть чехарда версий-однодневок, которые исчезают, "как слезы в дожде"(с). Между прочим, сейчас у Python2 еще остается шанс стать долговременным стандартом (де-факто) -- просто за счет: а) неизменяемости и стабильности (Python 3 позволяет себе deprecation removals как минимум в библиотеках, что потенциально может сломать обратную совместимость); б) плюс PyPy уже заявил, что собирается поддерживать его неограниченно долго, т.к. внутренности PyPy реализованы на Python2, а переписывать ради переписывания не нужно.
ну вам там выше написали, как одним шаловливым движением хвоста можно все взять и поломать, даже с предопределенными зависимостями.Пипи тоже допипикаетсо ;-) Их вот, кстати, и не жалко совсем.
Почему не жалко-то?
> Почему не жалко-то?потому что красиво но феерически бесполезно в реальной жизни.
> потому что красиво но феерически бесполезно в реальной жизни.Define "реальная жизнь"?
>> потому что красиво но феерически бесполезно в реальной жизни.
> Define "реальная жизнь"?ну вот давай ты на нем запустишь пресловутый hg - с минимальным набором дополнений, которые берутся не из общей поставки, а из репо?
> ну вот давай ты на нем запустишь пресловутый hg - с минимальным
> набором дополнений, которые берутся не из общей поставки, а из репо?Ну да, подколол, подколол -- сами разрабы пишут, что не сработает нормально из-за проблем с C API. Но при этом почему-то упорно пытаются заставить.
Я с ним работал во вполне реальной -- хотя и очень нишевой (интерпретация результатов в химии) -- жизни еще с тех времен, когда он был Psyco.
> Ну да, подколол, подколол -- сами разрабы пишут, что не сработает нормальнозаметим, я эту писанину не читал ;-) Просто предположил, что хрена там что запустится.
> Но при этом почему-то упорно пытаются заставить.
ну тогда может еще через годик случится чудо и будет гарантированная платформа для запуска древних четвертых версий - если всем повезет.
> Я с ним работал во вполне реальной -- хотя и очень нишевой (интерпретация результатов в химии)
ну так ты ее, поди, мог самостоятельно поправить по месту, если бы понадобилось.
А исходники hg править - занятие крайне унылое, слишком много и запутанно.
потому что разрабатывать большие проекты на динамическом нефункциональном языке просто противопоказано
Питон хорош совершенно для другого - избавляет во время разработки от необходимости перекомпилировать и перезапускать, а также не мучаться с системой билда проекта, что в совокупности феерически ускоряет скорость разработки, пока весь проект возможно удерживать у себя в голове
> первые попытки портирования были предприняты ещё в 2008 году
> форсированном режиме адаптация для работы с Python 3 началась в 2015они бы за 12 лет его с нуля на ассемблер переписали под все платформы, а за 5 лет на Си или том же rust
>> первые попытки портирования были предприняты ещё в 2008 году
>> форсированном режиме адаптация для работы с Python 3 началась в 2015
> они бы за 12 лет его с нуля на ассемблер переписали под
> все платформы, а за 5 лет на Си или том же
> rustпочему же ты еще этого не сделал?
А, ну да, ты ж не умеешь кодить...
Те, кто умеют, в этот тред не заходят. Потому что тут их обзовут вебмакаками и начнут измерять длину хвоста.
ну, в штанину пусть спрячут, что-ли? И какие-нибудь модные сапожки, чтоб кисточка из подворотиков не высовывалась.
> Те, кто умеют, в этот тред не заходят. Потому что тут их
> обзовут вебмакаками и начнут измерять длину хвоста.Те, кто умеют, прежде всего знают цену словам «надо переписать на...».
> почему же ты еще этого не сделал?А зачем, если есть git?
> они бы за 12 лет его с нуля на ассемблер переписали под
> все платформы, а за 5 лет на Си или том же
> rustВполне можно было взять компилируемый Питон, ака Ocaml. И наваять примерно за то же время.
> Вполне можно было взять компилируемый Питон, ака Ocaml. И наваять примерно за
> то же время.много проектов схожего размера уже наваяли-то?
Чай вас в гугеле не забанили. Или вы даже названия INRIA не знаете?
Лет 15 назад, когда у меня был большой по тем временам почтовый трафик (пришлось городить кластер из 10 серверов и лепить кластеризацию на колене), использовал я graylistd, который на питоне. Естественно производительности не хватало ни хрена, так что я разозлился и переписал на окамле.Получилось неплохо, кода кот наплакал, а делает что надо и притом быстро.
Покуда оно на продакшене падать не начало при больших объемах базы, причем падать где-то сильно глубоко внутри окамлих библиотек. С тех пор я на них несколько в обиде.
> Покуда оно на продакшене падать не начало при больших объемах базы, причем падать где-то сильно глубоко внутри окамлих библиотек. С тех пор я на них несколько в обиде.Насколько я понимаю, это что-то там внутри List.map. Мы над этим работаем - надеюсь, к весне List.map будет с хвостовой рекурсией.
пятнадцать лет работаете? Потом они удивляются, что экзотический язычок что-то так и не стал популярен...
Я не удивляюсь, т.к. прекрасно знаю, что движет индустрией. :-) Но если писать для себя, то можно и нормально выбрать язык. :-)
До сих пор используем в проде 2.3.2. То что было на 2.7 - снабдили from __future__ и за 3 года урывками переписали на 3. Ну как переписали - в основном убирали идиотизм в виде .decode().encode() и прочие издержки неюникодности. Заодно обнаружили кое-где 3-5 кратный рост производительности.Как так можно было относится к Mercurial - непонятно. Думаю, вероятность ошибок сильно преувеличена и это просто очередное интернет-нытье.
> Как так можно было относится к Mercurial - непонятно. Думаю, вероятность ошибок сильно преувеличена и это просто очередное интернет-нытье.Ну вод представьте, что у проекта три с половиной разработчика, да и тем работают над ним урывками, когда есть свободное время.
там их не то чтобы три, но им действительно было чем и без того заниматься - проект, с-ка, большой получился.Есть подозрение, что изначальные разработчики такого не планировали.
Выйдет скоро Python 4 и все эти портирование и переписывание коту под хвост.
> Выйдет скоро Python 4 и все эти портирование и переписывание коту под
> хвост.ну нет, так не делается.
Сначала-то, безусловно, 3.9
Потом, возможно - 3.99А когда закончат переписывать - то, конечно же, безусловно - 4. А поддержку нинунанинуна 3.x дропнут через неделю. Чтоб неповадно было.
Питон - он такой. Сначала написали, потом подумали.
> Питон - он такой. Сначала написали, потом подумали.неее, мы не такие!
Мы потом еще раз написали - и еще раз подумали. А потом и еще, и можем повторить!
мухаха. нет тестов - просто смиритесь и умрите. Git решал, решает и продолжит решать!
> так как при портировании было принято решение постепенно адаптировать код на Python 3, сохраняя поддержку Python 2, код оброс множеством хаков для совмещения Python 2 и 3, которые после прекращения поддержки Python 2 придётся вычищать.Вот нахрена? Взяли бы и начали писать следующую мажорную версию полностью на Python 3 в 2015-м году, глядишь и уже и дописалибы и без костылей.
> Вот нахрена?потому что любители модного-молодежного "все сломать, а потом незнамосколько писать с нуля, чтобы потом повторить, так и не доделав ни разу" - уже все равно пользуются единственноверным git...простите, gitlabce, "с встроенным редактором".
А те, кому на самом деле хотелось hg - могли немного расстроиться, обнаружив перспективу лет этак пять обойтись без исправлений ошибок и совместимости с уже существующими extensions, а так же самостоятельно собирать себе пихон 3 в системах, где его еще не существовало.
> Взяли бы и начали писать следующую мажорную версию полностью на
> Python 3 в 2015-м году, глядишь и уже и дописалибы и
> без костылей.нет, еще раза три переписали бы - потому что пихонов-три с тех пор вышло четыре штуки, если считать недописанный 3.9
И каждый норовил что-то сломать - разработчикам понравилось не заморачиваться совместимостью.Собственно, нынешний лидер проекта, который как раз в 15м был сторонником этой идеи, нынче крестится и бормочет "слава тебе, Господи!", что хотя бы 3.5 проскочили.
> Вот нахрена? Взяли бы и начали писать следующую мажорную версию полностью на
> Python 3 в 2015-м году, глядишь и уже и дописалибы и без костылей.Может, потому что когда ты уже написал нечто работаюшее, кодить это с ноля еще раз по причине "автор ЯП прикололся" как-то не очень возбуждает? :)
Носятся с этим Гвидобейсиком, как с торбой расписной. А торба-то худая много лет уже.
> Носятся с этим Гвидобейсиком, как с торбой расписной. А торба-то худая много лет уже.Дожили, #$% - устами iZEN'а глаголет истина... :\