Здравствуйте, Erop, Вы писали:
E>>>В целом мне лично не понятно, зачем вообще переписывать что-то большое с P2 на P3, а не на какой-нибудь более типизированный язык...
N>>Затем, что для обычного проекта такой переход на Py3 раз в 10-100 дешевле переписки на совсем другой язык. E>А вообще не переписывать -- ещё дешевле... Зачем вообще P2 менять на P3?
Ну если у тебя ну очень низкосистемные задачи — можешь не переписывать. Я в этом смысле приветствовал, например, сохранение Perl4 во FreeBSD — была простая понятная вещь, как раз для двухстраничного клея. Но его перестали развивать и лечить...
А если что-то прикладное, то, например, кошмар путаний между str и unicode в Py2 уже заслуживал нормализации.
E> Это, примерно, как переписать что-то с С++ на D, только ещё более бессмысленно...
Здравствуйте, Nuzhny, Вы писали:
N>>Динамичность и несовместимые изменения ортогональны. Вон в C++ тоже много вещей, которые с 17 или 20 объявлены удалёнными — и что?
N>А то, что тебе об этом скажет компилятор. В случае с Питоном ты не узнаешь о проблемах, пока этот код не выполнится. Этого разве мало?
Про C++ — таких случаев полно, из модификации правил выбора перегруженной функции, подстановки конкретной инстанциации шаблона и т.п. — есть народ, который хорошо такие вещи знает. Но я в них стараюсь не лезть, и поэтому не нашёл навскидку примеров, где бы фича поменялась без слома компиляции.
Но всё равно это не про то, это не про динамику как таковую, это уже про метапрограммирование. Аналог варианта C++ это если, например, метод просто исчез из класса. Такие вещи для Питона находятся статическими анализаторами (если ты не читерствуешь с какой-то хитрой подстановкой, генерацией класса в рантайме и т.п.); опять же, я стараюсь по максимуму обходиться без такого. Да, есть любители всё построить на метаклассах, на генераторах классов и т.п. Но мы в своих проектах пишем так, чтобы, грубо говоря, можно было перенести на какую-нибудь Java 1:1 хоть завтра без напряга мозга, только чуть уточнить самый системный уровень.
Итого, тут я скорее принимаю аргумент, но в том, что в Питоне ты не обязан писать так, чтобы статический анализ не сработал, но слишком легко сделать так, и есть много любителей так делать. Можно их бить для улучшения мировой кармы
Здравствуйте, netch80, Вы писали:
N>И в третий раз повторю только на этом форуме: мне после CVS было легче перейти на Git, чем SVN, Hg или ещё какой-то временно модный ужас.
Почему?
N>"Напрямую из CVS" для Hg это миф. Зачем, например, у Hg раздельные pull и update? В CVS такого не было.
Наверное, для симметрии. Раздельные commit и push понятно почему, вот и сделали раздельные pull и update.
А зачем в гите измененные файлы надо add перед commit? Он же и так видит, какие файлы изменились. И почему ходовая команда "покажи diff между моей рабочей версией и последней версией из репозирория" такая длинная.
А еще, зачем push для меток и push вообще — это разные команды? Как вообще там это сделано? Там что, для меток отдельный blokchain ведется?
Здравствуйте, Erop, Вы писали:
E>Просто P2 и P3 шибко разные. Первый про списки, а второй про итераторы, например. E>В целом мне лично не понятно, зачем вообще переписывать что-то большое с P2 на P3, а не на какой-нибудь более типизированный язык...
Я так понимаю, у них с поддержкой даже одной версии неочень
M>Это должно было показать, что нет никакой разницы между питоном и C++, что ли?
M>C++: создать сборочный файл, запустить компиляцию, запустить файл M>Python: python файл_в_котором_кот.py
M>
Здравствуйте, kaa.python, Вы писали:
KP>Сложнее всё-же. Во-первых, телодвижений больше чем с Python, хотя и не так много как было раньше. Во-вторых, к проекту нужны тесты, тут еще больше сложностей.
А-ха-ха, а к Питону не нужны тесты
KP>В-третьих, если (когда) проект вырастет, CMake превратится в ад. В-четвертых, когда проект вырастет, с большой вероятностью о предсобранных в vcpkg пакетах придется забыть.
Если проект вырастет на Питоне, там вообще полный ад будет.
Хотя, на Питоне проекты большими редко вырастают, потому что начинают обваливаться под собственной тяжестью достаточно скоро
KP>C++ зык прекрасный, но вот сборочно-тестовая-деплойная инфраструктура, мягко говоря, оставляет желать лучшего.
Проект на питоне строк от 1000 уже на другую машину просто так обычно не перенесешь, но да, инфраструктура плохая у C++
Здравствуйте, Pzz, Вы писали:
V>>Например, вот так: V>>
V>>LIBS += -lcryptopp
V>>
Pzz>Это все хорошо, когда нужная тебе библиотека есть в виде стандартного пакета для твоего дистрибутива твоей любимой ОС. А когда нету, начинается беда.
Здравствуйте, Pzz, Вы писали:
E>>Просто P2 и P3 шибко разные. Первый про списки, а второй про итераторы, например. E>>В целом мне лично не понятно, зачем вообще переписывать что-то большое с P2 на P3, а не на какой-нибудь более типизированный язык...
Pzz>Не очень понятно, почему бы на P2 и не осталься. Ясно же, что это два достаточно разных языка, и P3 никогда не вытеснит P2, они так и будут вечно сосуществовать.
Я когда-то пописывал на 2.7, а тут попробовал 3.6.
Если честно, кроме мелких отличий синтаксиса никакой особой разницы и не заметил.
Но я так, видимо, нуб, не проникнувшийся ни идеологией П2, ни идеологией П3
Здравствуйте, Pzz, Вы писали:
Pzz>Дело не в динамике, а в том, что кое-кто, не подумав, вносит ломающие изменения в язык.
Pzz>Мораль: серьезные проекты можно писать только на языках, для которых верно хотя бы одно из двух: 1) у языка есть несколько независимых, влиятельных реализаций 2) за языком стоят люди, которым можно доверять
Только я бы уточнил: вот доверяешь ты такой людям, доверяешь — а потом раз — и трамвай переехал. Ну, или просто задолбало их пилить дальше
Здравствуйте, novitk, Вы писали:
N>>Не, не, не, ты сам начал говорить про С++. N>Я начал говорить про C+++(три плюса!) — вымышленный, похожий, но не совместимый с C++ язык для аналогии с py2->py3.
Для статически типизируемого языка гораздо проще написать конвертер. Те же PVS, уверен, с радостью бы взялись, если бы такая необходимость появилась бы
Здравствуйте, Marty, Вы писали:
Pzz>>Это все хорошо, когда нужная тебе библиотека есть в виде стандартного пакета для твоего дистрибутива твоей любимой ОС. А когда нету, начинается беда.
M>А для питона как?
Не знаю.
Для Go очень хорошо: делаешь import, указав прям путь к гитхабовскому репозиторию
Здравствуйте, so5team, Вы писали:
S>IDEA и VisualStudio сильно популярнее vim-а и emacs-а. Что не мешает отдельным людям быть продуктивнее именно с vim/emacs. S>Собственно, почему бы отдельным разработчикам не быть продуктивнее именно с hg, а не с git-ом.
С такой формулировкой я абсолютно согласен Вопрос-то в том, что другие сотудники будут в среднем менее продуктивны или их сложнее будет найти.
В частном случае что угодно может быть эффективнее, но в общем случае и в долгосрочной перспективе и для сотрудников и для компаний git однозначно предпочтительней.
Здравствуйте, 13akaEagle, Вы писали:
Pzz>>Не знаю. Pzz>>Для Go очень хорошо: делаешь import, указав прям путь к гитхабовскому репозиторию
E>pip install git+https://github.com/...
pip install гадит в какую-то свою кучу, общую для всех, а Go управляет зависимостями для каждого проекта отдельно и независимо от прочих проектов.
Здравствуйте, Pzz, Вы писали:
Pzz>pip install гадит в какую-то свою кучу, общую для всех, а Go управляет зависимостями для каждого проекта отдельно и независимо от прочих проектов.
Для питона принято создавать виртуальное окружение, наружу пакеты не утекают.
Здравствуйте, 13akaEagle, Вы писали:
Pzz>>pip install гадит в какую-то свою кучу, общую для всех, а Go управляет зависимостями для каждого проекта отдельно и независимо от прочих проектов. E>Для питона принято создавать виртуальное окружение, наружу пакеты не утекают.
Здравствуйте, anonymous, Вы писали:
A>Здравствуйте, Буравчик, Вы писали:
Б>> lines = list(islice(sys.stdin, count))
A>Память больше не ресурс? А если файл размером в терабайт?
Тогда весь код надо переписывать, а не только эту строку.
Здравствуйте, kaa.python, Вы писали:
KP>Ну, разве что это особенность ML. Я довольно много делал проектов на Python и с описанным сталкивался только по молодости и глупости, когда про venv не знал
Далеко не только ML. Если в requirements.txt прописано десяток зависимостей — гемморрой с подбором версий этих зависимостей практически гарантирован, как показывает практика.) Особенно, если проект не обновлялся автором год-другой, тут уже начинаешь думать, что проще — написать свой аналог или починить зависимости в исходном проекте.)
