Python в больших проектах
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 14.01.20 20:39
Оценка: 5 (5) +15
Новость про Mercurial.
Удивительное дело, что такой большой проблемой является переход на новую версию языка, которая появилась уже более 10 лет назад.
Спрашивается: нахер оно тогда надо, писать нетленку на динамических языках? Только прототипы! Тут же и тесты не особо помогут, потому что и их надо переписывать. Я раньше как-то не понимал всей глубины проблемы, но сейчас удивляюсь, как вообще можно что-то большое делать на динамике. Плюсовые и шарповые проекты не всегда легко, но достаточно уверенно переползают со стандарта на стандарт, на новые компиляторы и платформы. И 100% покрытия тестами в них нет, но кажется, что само переползание чаще лечит прошлые баги, чем добавляет новых.
Вот, просто ужаснулся и захотелось поделиться.
Re: Python в больших проектах
От: Sheridan Россия  
Дата: 15.01.20 05:28
Оценка: +1 -2 :))) :))
Я как то писал про то что питон нужно в топку, не помню уже даже когда и контекст. Но некоторые личности до сих пор мне это вспоминают
Matrix has you...
Re[4]: Python в больших проектах
От: Igore Россия  
Дата: 15.01.20 10:59
Оценка: +5 :)
Здравствуйте, velkin, Вы писали:

KP>>В C++ и маленьких утилитах другая проблема. К тому времени когда ты соберешь в кучу все, что нужно для маленького проекта на C++, проект на Python уже будет радовать результатами.

KP>>Можно-можно. Python по-умолчанию доступен много где.
KP>>И в Python у тебя уже будет все что хочешь либо из коробки, либо путем добавления одной строчки в requirements.txt. Ну а как дела в C++ с подключением алгоритмов и библиотек, думаю, все и так знают.

V>Да, знаем.

Не похоже

V>Например, вот так:

V>
V>LIBS += -lcryptopp
V>

А так же LIB_PATH, INCLUDE_PATH, а, библиотеку же еще скачать и собрать надо, и хранить, и ключи компиляции/линковки должны совпадать, под Linux еще RPATH или LD_LIBRARY_PATH + возможные зависимости. Еще и инсталятор нужно, под Windows хоть из той же папки грузится, тут хоть архив на первое время можно сделать.

V>Всё, я перетрудился добавляя сторонние библиотеки в свой проект, пойду отдохну. Другое дело, что не нужно заниматься популизмом. Или нужно?

Не нужно

V>Проблема здесь вовсе не в добавлении сторонних библиотек, а в том, что:


V>1) Открытый интерфейс этих библиотек не соответствует собственному восприятию понятий, причём в любом языке программирования и практически любой библиотеке алгоритмов. Потому когда кто-то говорит, я сел и написал за 5 минут на Python, и сторонние библиотеки подключил легко, а вот в C++ замучался, очень тяжело. Хочется спросить, а сколько времени ушло на изучение того же Python. То есть я зная как подключить библиотеки в C++ и чисто для примера не зная как это делается в Python, всё равно как бы должен считать, что в Python это всё проще.

Мелочи.

V>Название проекта: project_name

V>IDE: qt creator
Прелесть Qt в том что тебе в 90% случаях не придется подключать ничего другого, на нём прототипы С++ писать можно относительно легко, или под Linux, apt-get install lib-dev + find_package, или студийный nuget основной сценарий использования стороних либ покрывает.

V>Создаём папку project и копипастим два файла:

Да, для Qt можно

V>Но вот вопрос, зачем было называть файл C++ project_name. А затем, чтобы положить в эту же папку исходники других языков. Если бы это был hello_world:

Да ни для кого hello world почти не нужен, а проблема С++ в скудной stl, чуть в сторону и тебе нужно network, db, xml, ini, json, csv, log, получить директорию пользователя куда можно файлы сохранить, открыть файл системным приложением, etc, и ничего этого нет, вперед читать искать библиотеки который тебе нужны, качать, компилировать, подключать, настраивать, собирать инсталятор, или брать монстров Qt, boost где просто не нужно будет скорей всего ничего другого искать.

V>Ладно, это всё были хелло ворлды. Если не жалко времени приведи конкретный "внушительный" пример, чтобы я мог посмотреть на код и сказать, — "О, Python это круто, а вот тот же самый проект или прототип на C++ полное говно".

Именно что хелло ворлды, хорошо, прототип, отслеживать выложеную в интеренете БД в формате ACCESS, после скачать и обновить данные в твоей локальной postgresql базе, на python-e будет в разы проще сделать. А для C++ можешь попробовать для разных системы прикинуть какие библиотеки тебе понадобятся для реализации этого несложного приложения.
Re[5]: Python в больших проектах
От: Pzz Россия https://github.com/alexpevzner
Дата: 15.01.20 13:44
Оценка: +2 :))) :)
Здравствуйте, kaa.python, Вы писали:

KP>Отвлеченный вопрос, как ты находишь время такие простыни ответов писать? Их даже читать долго же


А ему библиотеки подключать очень легко дается. Вот, время и освобождается
Re: Python в больших проектах
От: velkin Удмуртия http://blogs.rsdn.org/effective/
Дата: 15.01.20 04:54
Оценка: +1 -3 :)
Здравствуйте, Nuzhny, Вы писали:

N>Спрашивается: нахер оно тогда надо, писать нетленку на динамических языках? Только прототипы!


По поводу прототипов. Некоторые обвиняют тот же C++ в излишней сложности для написания простеньких утилит. Тем не менее в нём существуют такие понятия как физическое и логическое постоянство. Можно написать весь проект в одном файле. Можно определять члены класса внутри класса. Это влияет на компиляцию, но не на результат.

Таким образом можно ли сказать, что написание простенького прототипа на динамическом языке действительно быстрее. К примеру, для того, чтобы запустить скрипт на динамическом языке нужен интерпретатор, это программа, которую так же приходится устанавливать (пусть даже она входит в состав другой программы), как и пакет утилит для компиляции.

Следующим пунктом идут алгоритмы. Они могут быть полностью своими или чужими. Чужие можно использовать через свою обёртку и соответственно напрямую без обёртки. Если алгоритмы свои, или используются через свою обёртку, то есть ли разница в языке программирования.

Ещё один момент, динамические языки хороши для связывания различных компонентов на этапе выполнения. С другой стороны, при написании прототипа всё это не имеет смысла, так как программная система и так полностью под управлением программиста пишущего код.

Главная моя мысль здесь не в том чтобы отказаться от динамических языков программирования для прототипирования, а в том, что в этом плане разницы между ними и языками с компиляцией практически нет. Это больше похоже на самообман, когда кто-то думает, что прототипировать нужно обязательно на динамическом языке программирования.
Re[2]: Python в больших проектах
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 15.01.20 05:23
Оценка: +4
Здравствуйте, velkin, Вы писали:

V>По поводу прототипов. Некоторые обвиняют тот же C++ в излишней сложности для написания простеньких утилит. Тем не менее в нём существуют такие понятия как физическое и логическое постоянство. Можно написать весь проект в одном файле. Можно определять члены класса внутри класса. Это влияет на компиляцию, но не на результат.


В C++ и маленьких утилитах другая проблема. К тому времени когда ты соберешь в кучу все, что нужно для маленького проекта на C++, проект на Python уже будет радовать результатами.

V>Таким образом можно ли сказать, что написание простенького прототипа на динамическом языке действительно быстрее. К примеру, для того, чтобы запустить скрипт на динамическом языке нужен интерпретатор, это программа, которую так же приходится устанавливать (пусть даже она входит в состав другой программы), как и пакет утилит для компиляции.


Можно-можно. Python по-умолчанию доступен много где.

V>Следующим пунктом идут алгоритмы. Они могут быть полностью своими или чужими. Чужие можно использовать через свою обёртку и соответственно напрямую без обёртки. Если алгоритмы свои, или используются через свою обёртку, то есть ли разница в языке программирования.


И в Python у тебя уже будет все что хочешь либо из коробки, либо путем добавления одной строчки в requirements.txt. Ну а как дела в C++ с подключением алгоритмов и библиотек, думаю, все и так знают.
Re[2]: Python в больших проектах
От: Privalov  
Дата: 15.01.20 07:00
Оценка: +1 :)))
Здравствуйте, Sheridan, Вы писали:

S>Я как то писал про то что питон нужно в топку, не помню уже даже когда и контекст. Но некоторые личности до сих пор мне это вспоминают


В печку же...

Некоторые личности также знают, что иногда ты его из печи вытаскиваешь. Правда, только с твоих слов.

Я неоднократно писал тут что у меня есть проекты на питоне и я пользую этот язык там где он к месту.

Re: Python в больших проектах
От: rudzuk  
Дата: 15.01.20 08:44
Оценка: +4
Здравствуйте, Nuzhny, Вы писали:

N> Спрашивается: нахер оно тогда надо, писать нетленку на динамических языках? Только прототипы!


Сперва прототип, а потом по классику: коготок увяз, всей птичке пропасть.
avalon/2.0.6
Re[7]: Python в больших проектах
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 18.01.20 13:51
Оценка: -2 :))
Здравствуйте, kaa.python, Вы писали:

KP>Сложнее всё-же. Во-первых, телодвижений больше чем с Python, хотя и не так много как было раньше. Во-вторых, к проекту нужны тесты, тут еще больше сложностей.


А-ха-ха, а к Питону не нужны тесты


KP>В-третьих, если (когда) проект вырастет, CMake превратится в ад. В-четвертых, когда проект вырастет, с большой вероятностью о предсобранных в vcpkg пакетах придется забыть.


Если проект вырастет на Питоне, там вообще полный ад будет.
Хотя, на Питоне проекты большими редко вырастают, потому что начинают обваливаться под собственной тяжестью достаточно скоро

KP>C++ зык прекрасный, но вот сборочно-тестовая-деплойная инфраструктура, мягко говоря, оставляет желать лучшего.


Проект на питоне строк от 1000 уже на другую машину просто так обычно не перенесешь, но да, инфраструктура плохая у C++
Маньяк Робокряк колесит по городу
Re[10]: Python в больших проектах
От: Pzz Россия https://github.com/alexpevzner
Дата: 20.01.20 15:37
Оценка: +1 :)))
Здравствуйте, 13akaEagle, Вы писали:

Pzz>>pip install гадит в какую-то свою кучу, общую для всех, а Go управляет зависимостями для каждого проекта отдельно и независимо от прочих проектов.

E>Для питона принято создавать виртуальное окружение, наружу пакеты не утекают.

Адский ад, в общем
Re[4]: скала
От: novitk США  
Дата: 16.01.20 06:13
Оценка: 3 (3)
Здравствуйте, Sharov, Вы писали:

В>> Scala offers very limited community presence.

В>> It is not the easily adaptable language.
В>> Offers very limited backward compatibility

S>А что, скала так быстро развивается или сложный язык сам по себе?


Развиваeтся нормально. Скоро должен начаться транзит scala2->scala3, как десять лет назад у Питона.

Проблема с популярностью из за:
а) сложность в смысле "хаскеля", а не "плюсов". Он гибридный и можно изпользовать без монад и теор.кат, но без них не модно.
б) Медленный классический цикл разработки, без IDE не разобраться из за implicits. Компилятор тоже дикий тормоз.
в) Бабло. Одно дело Гугл, МС, Эппл или даже ДжетБрэйн с Мозилой, а другое дело швейцарские студенты.

Сначала народ на него набросился, думая как всегда, что это "серебряная пуля", тут тебе и FP, ADT и медленное переползания с Явы. А потом посчитали и поняли, что реально эффект не так уж и велик, а люди нужны квалифицированные и дорогие.
Re[10]: Python в больших проектах
От: so5team https://stiffstream.com
Дата: 16.01.20 12:29
Оценка: 1 (1) +2
Здравствуйте, Mamut, Вы писали:

M>>Странный ты. Гугл придумал GoLang как замену Python.


M>Он придумал GoLang как проект, чтобы занять умных чуваков, которым было скучно.


Как бы наоборот: умные чуваки в Google придумали GoLang, чтобы не писать тормознутый код на Python-е, и чтобы не писать сложный и многословный код на C++ и Java. ЕМНИП, стартовал GoLang вообще как подпольный проект, который делали несколько человек втихаря. Просто это были не самые рядовые человеки.
Re[2]: Python в больших проектах
От: Farsight СССР  
Дата: 15.01.20 05:49
Оценка: +1 :))
Здравствуйте, Sheridan, Вы писали:

S>Я как то писал про то что питон нужно в топку, не помню уже даже когда и контекст. Но некоторые личности до сих пор мне это вспоминают


Не благодари
Автор: Sheridan
Дата: 26.02.08
.
</farsight>
Re[3]: Python в больших проектах
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 15.01.20 07:17
Оценка: +2 -1
Здравствуйте, kaa.python, Вы писали:

V>>По поводу прототипов. Некоторые обвиняют тот же C++ в излишней сложности для написания простеньких утилит. Тем не менее в нём существуют такие понятия как физическое и логическое постоянство. Можно написать весь проект в одном файле. Можно определять члены класса внутри класса. Это влияет на компиляцию, но не на результат.


KP>В C++ и маленьких утилитах другая проблема. К тому времени когда ты соберешь в кучу все, что нужно для маленького проекта на C++, проект на Python уже будет радовать результатами.


Это отчасти справедливо только для очень маленьких утилит, в которых очень много сторонних библиотек. Что-то большее писать, чем хеловорд — это боль


V>>Следующим пунктом идут алгоритмы. Они могут быть полностью своими или чужими. Чужие можно использовать через свою обёртку и соответственно напрямую без обёртки. Если алгоритмы свои, или используются через свою обёртку, то есть ли разница в языке программирования.


KP>И в Python у тебя уже будет все что хочешь либо из коробки, либо путем добавления одной строчки в requirements.txt. Ну а как дела в C++ с подключением алгоритмов и библиотек, думаю, все и так знают.


Ага. pip install bl-bla. Ой, не работает. Гуглим. А-а-а, надо откатить pip на конкретную версию, иначе эту хрень не поставить
Маньяк Робокряк колесит по городу
Re[4]: Python в больших проектах
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 15.01.20 12:15
Оценка: +3
Здравствуйте, velkin, Вы писали:

V>Да, знаем.


Уверен что знаешь? С чего вдруг на машине должен быть QMake (у меня вообще никогда не было)? Показал бы уж как всё легко и просто, ну и конечно кроссплатформенно, на Makefile.

V>Например, вот так:

V>
V>LIBS += -lcryptopp
V>


Отвлеченный вопрос, как ты находишь время такие простыни ответов писать? Их даже читать долго же
Re[8]: Python в больших проектах
От: Pzz Россия https://github.com/alexpevzner
Дата: 15.01.20 13:40
Оценка: +1 :))
Здравствуйте, Nuzhny, Вы писали:

N>>>Я пару раз попадал на это

В>>На ц++ хелл? Или откатывание пипа?

N>На откатывание пипа. Вручную подбирал версию пипа и библиотек.


Хорошую вещь пипом не назовут
Re: Python в больших проектах
От: novitk США  
Дата: 15.01.20 14:29
Оценка: +3
Здравствуйте, Nuzhny, Вы писали:

N>Новость про Mercurial.

N>Удивительное дело, что такой большой проблемой является переход на новую версию языка, которая появилась уже более 10 лет назад.

Заголовок не соответствует содержанию. Чувак из меркуриала жалуется на переход py2->py3, а не на динамику. Представь себе C++ теряет обратную совместимость и остается без поддержки и всем предлагается перейти на С+++? Сильно тебе статика поможет?

На питоне пишутся огромные систему. Ключевой система по расчету риска для двух инвест.банка написана на Питоне (>1мм LoC) на который перешли со .... Smalltalk-a. Сейчас я работаю с такой же системой в еще одном инвест банке(все три входят в первую пятерку в мире), где вместо Питона решили использовать Скалу. Результат в продуктивности имхо сильно хуже чем с Питоном, хотя это пожалуй самый продвинутый язык в относительном мэйнстриме. Поэтому кванты потихоньку саботируют и пишут на питончике, хотя в IT конечно так сделать наверно не дадут.
Re[11]: Python в больших проектах
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 18.01.20 13:42
Оценка: +1 :))
Здравствуйте, kaa.python, Вы писали:


KP>Это просто больно читать... virtualenv, venv море других. Просто не надо валить всё в системные библиотеки Питона и всё будет хорошо.


К тому времени когда ты соберешь в кучу все, что нужно для маленького проекта на Python, проект на C++ уже будет радовать результатами.
Маньяк Робокряк колесит по городу
Re[10]: Python в больших проектах
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 16.01.20 12:34
Оценка: 3 (1) +1
Здравствуйте, Mamut, Вы писали:

M>Он придумал GoLang как проект, чтобы занять умных чуваков, которым было скучно.


Совсем нет. Я уже приводил эту картинку, но повторюсь:
  Картинка
Re: Python в больших проектах
От: kov_serg Россия  
Дата: 15.01.20 04:10
Оценка: 2 (2)
Здравствуйте, Nuzhny, Вы писали:

N>Новость про Mercurial.

N>Вот, просто ужаснулся и захотелось поделиться.

# Mercurial will never work on Python 3 before 3.5 due to a lack
# of % formatting on bytestrings, and can't work on 3.6.0 or 3.6.1
# due to a bug in % formatting in bytestrings.
# We cannot support Python 3.5.0, 3.5.1, 3.5.2 because of bug in
# codecs.escape_encode() where it raises SystemError on empty bytestring

Re[2]: Давайте сравним
От: alexzzzz  
Дата: 15.01.20 19:06
Оценка: 2 (1) +1
Здравствуйте, Ватакуси, Вы писали:

  C#
using System;
using System.Globalization;
using System.IO;
using System.Linq;

internal class Program
{
    private static void Main()
    {
        var records = (from line in File.ReadAllLines("ts1.txt").Skip(1).Where(line => !string.IsNullOrWhiteSpace(line))
                       let items = line.Split('\t')
                       let date = DateTime.Parse(items[0], CultureInfo.InvariantCulture)
                       let value = items[1].StartsWith("Missing_") ? double.NaN : double.Parse(items[1], CultureInfo.InvariantCulture)
                       select (date, value)).ToArray();

        int? firstMissing = null;
        for (var i = 0; i < records.Length; i++)
        {
            switch (firstMissing.HasValue, double.IsNaN(records[i].value))
            {
                case (false, true):
                    firstMissing = i;
                    break;
                case (true, false):
                    FillMissingValues(firstMissing.Value, i - 1);
                    firstMissing = null;
                    break;
            }
        }

        void FillMissingValues(int first, int last)
        {
            var startDate = records[first - 1].date;
            var startValue = records[first - 1].value;
            var timeDiff = records[last + 1].date - startDate;
            var valueDiff = records[last + 1].value - startValue;

            for (var i = first; i <= last; i++)
            {
                var t = (records[i].date - startDate) / timeDiff;
                records[i].value = startValue + t * valueDiff;
                Console.WriteLine(records[i].value);
            }
        }
    }
}

  Результат
32,540000000000006
32,120000000000005
32,5525
29,38
29,286
28,884
30,512
29,648
29,59
30,95
31,22
31,4
29,69666666666667
29,473333333333333
29,634999999999998
29,356666666666666
29,7825
28,15
26,9275
27,375

Простая линейная интерполяция с такими же ошибками. Не знаю, что требуется делать, если отсутствуют крайние значения, поэтому проигнорировал.
Re[7]: Python в больших проектах
От: 13akaEagle Россия  
Дата: 20.01.20 10:41
Оценка: 1 (1) +1
Здравствуйте, Pzz, Вы писали:

M>>А для питона как?

Pzz>Не знаю.
Pzz>Для Go очень хорошо: делаешь import, указав прям путь к гитхабовскому репозиторию

pip install git+https://github.com/...
Re[13]: Python в больших проектах
От: jahr  
Дата: 22.01.20 06:09
Оценка: 1 (1) +1
Здравствуйте, kaa.python, Вы писали:

KP>Ну, разве что это особенность ML. Я довольно много делал проектов на Python и с описанным сталкивался только по молодости и глупости, когда про venv не знал


Далеко не только ML. Если в requirements.txt прописано десяток зависимостей — гемморрой с подбором версий этих зависимостей практически гарантирован, как показывает практика.) Особенно, если проект не обновлялся автором год-другой, тут уже начинаешь думать, что проще — написать свой аналог или починить зависимости в исходном проекте.)
Re: Python в больших проектах
От: Erop Россия  
Дата: 15.01.20 07:26
Оценка: +2
Здравствуйте, Nuzhny, Вы писали:

N>Вот, просто ужаснулся и захотелось поделиться.


Просто P2 и P3 шибко разные. Первый про списки, а второй про итераторы, например.
В целом мне лично не понятно, зачем вообще переписывать что-то большое с P2 на P3, а не на какой-нибудь более типизированный язык...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[4]: Python в больших проектах
От: Privalov  
Дата: 15.01.20 08:19
Оценка: +2
Здравствуйте, Sheridan, Вы писали:

S>Да-да, ты в том числе


А я что? Я ничего. Ты выдаешь нетленки на века. В результате тебя индекс, наверное, один из самых высоких на RSDN.

Я, кстати, с "питон в печку" не так, чтбы согласен. Прототипы, или что-нибудь по-быстромы проверить, на нем очень удобно. А вот в production с динамикой надо быть поосторожнее.
Re[4]: Python в больших проектах
От: Ватакуси Россия  
Дата: 15.01.20 09:10
Оценка: :))
M>Ага. pip install bl-bla. Ой, не работает. Гуглим. А-а-а, надо откатить pip на конкретную версию, иначе эту хрень не поставить
Никогда не встречал. Может не компилироваться из-за ц++ хелла на твоей машине, это да. Раза 3 или 4 приходилось долго танцевать.
Все будет Украина!
Re[9]: Python в больших проектах
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 15.01.20 10:54
Оценка: +2
Здравствуйте, Masterspline, Вы писали:

M>Я на Python не писал ничего серьезного, но давно понял, что любой проект сложнее скрипта из одного файла нужно начинать с установки и настройки virtual environment. Неужели кто-то делает по-другому...


Я также делаю, но оно же не обязательно будет работать. Ты ставишь requirements для одного проекта, пишешь код, например, сервера. Потом хочешь сделать, чтобы он распознавал котиков на фотках. Находишь предобученную модель, подключаешь tensorflow, а он не работает. Ему нужен другой python, более древний. И какой-нибудь другой protobuf. Или numpy. Потом выясняется, что это старая версия или версия, которая требует строго определённые версии пакетов, ни больше, ни меньше. Не случайно сейчас самые популярные репозитории начинают раздел Install со слов: "Скачайте такой-то Докер..." Как раз потому что в версиях Питона и библиотек разброд и шатание и не так просто подбирать рабочие комбинации для разных библиотек.
Re: Python в больших проектах
От: Pzz Россия https://github.com/alexpevzner
Дата: 15.01.20 12:54
Оценка: +2
Здравствуйте, Nuzhny, Вы писали:

N>Спрашивается: нахер оно тогда надо, писать нетленку на динамических языках? Только прототипы! Тут же и тесты не особо помогут, потому что и их надо переписывать. Я раньше как-то не понимал всей глубины проблемы, но сейчас удивляюсь, как вообще можно что-то большое делать на динамике. Плюсовые и шарповые проекты не всегда легко, но достаточно уверенно переползают со стандарта на стандарт, на новые компиляторы и платформы. И 100% покрытия тестами в них нет, но кажется, что само переползание чаще лечит прошлые баги, чем добавляет новых.


Дело не в динамике, а в том, что кое-кто, не подумав, вносит ломающие изменения в язык.

Мораль: серьезные проекты можно писать только на языках, для которых верно хотя бы одно из двух: 1) у языка есть несколько независимых, влиятельных реализаций 2) за языком стоят люди, которым можно доверять
Re[5]: Python в больших проектах
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 16.01.20 01:31
Оценка: +2
Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, Anton Batenev, Вы писали:


AB>>Гвидо покинул питон в 2018, гугл сделал ставку на го, который уже обошел питон по всем фронтам, кроме разве что ML да и то за счет инертности и числа либ. Лет 5 назад начинать проект на питоне было неплохим выбором, но надо вовремя уметь остановиться и принять, что py2 и py3 это разные языки. Плюс, кажется, последний собирается повторить судьбу Perl6.


S>Т.е. Вы не советуете в него инвестировать время? Я как раз начал его активно изучать. В связи с ML, конечно.

S>Perl6 потому что никто не будет использовать? Ну не думаю, в ml нонче столько народу, что ход у него будет неплохой.
S>Как по мне, но перпективы питона радужнее чем шарпа.

Ниши и подход к разработке Python и Go настолько разные, что они даже не особо конкуренты друг другу. Python еще будет жить очень долго, я бы скорее предположил что Go раньше помрет.
Отредактировано 16.01.2020 1:47 kaa.python . Предыдущая версия .
Re[5]: Python в больших проектах
От: Masterspline  
Дата: 16.01.20 06:08
Оценка: +2
Pzz>Потому, что проще сдохнуть, чем привыкнуть к этому вашему git'у. А у hg все команды идут напрямую из CVS, к которому программистов моего поколения еще в детском садике приучили (нам так воспиталка и говорила: "покакал — возьми листочек бумажки, подпиши на нем изменения и закоммитеть не забудь").

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

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

P.S. CVS я тоже застал (Opera3.5b сменила netscape 3 gold, mingw только появился на Win95 i486 с 8М памяти).
Re[7]: Python в больших проектах
От: Skorodum Россия  
Дата: 16.01.20 10:19
Оценка: -1 :)
Здравствуйте, kaa.python, Вы писали:

KP>Сложнее всё-же. Во-первых, телодвижений больше чем с Python, хотя и не так много как было раньше. Во-вторых, к проекту нужны тесты, тут еще больше сложностей.

Почему? Все есть, работает

KP>В-третьих, если (когда) проект вырастет, CMake превратится в ад.

ИМХО: вероятность сильно меньше, чем с питоном. От размера это не особо зависит, "правильный CMake (tm)" прекрасно масштабируется.

KP>В-четвертых, когда проект вырастет, с большой вероятностью о предсобранных в vcpkg пакетах придется забыть.

Почему? Все есть, работает

KP>C++ зык прекрасный, но вот сборочно-тестовая-деплойная инфраструктура, мягко говоря, оставляет желать лучшего.

Определенные усилия нужны. И дисциплина.
cmake
Re[9]: Python в больших проектах
От: Mamut Швеция http://dmitriid.com
Дата: 16.01.20 11:07
Оценка: +1 -1
M>Странный ты. Гугл придумал GoLang как замену Python.

Он придумал GoLang как проект, чтобы занять умных чуваков, которым было скучно.

M>Он же его и развивает (а Python уже нет). У них, конечно, есть проекты на GoLang. Неужели ты этого не знаешь? Или я что-то не так понял?


Что-то мне подсказывает, что у них есть проекты и на Питоне, и на Java, и на С++, и на C#, и на Хаскеле, и..., и..., и... Они развивают все эти языки? Гугл много какие проекты развивает по много каким разным причинам. Верить в то, что эти проекты умрут только со смертью Гугла, я бы не стал.


dmitriid.comGitHubLinkedIn
Re[9]: Давайте сравним
От: Ватакуси Россия  
Дата: 16.01.20 15:44
Оценка: 3 (1)
В>>Кстати, to_datetime справится с произвольной датой (и форматом) как parser.parse? Мне казалось, что он более капризный

Б>Думаю, что более капризный, но не уверен. Тоже хочу знать.

Б>У to_datetime под капотом, наверное, тот же код, что и в TimeStamp. А вот какие он умеет парсить даты/время я не знаю.
не совсем, там используется вот это:
https://github.com/pandas-dev/pandas/blob/c040f14574fcb7fd366858e22c5bdb393571236c/pandas/_libs/tslibs/parsing.pyx
_guess_datetime_format

Он тянет из dateutil parse сначала.
https://github.com/dateutil/dateutil/blob/110a09b4ad46fb87ae858a14bfb5a6b92557b01d/dateutil/parser/_parser.py

А потом уже пытается выяснить формат даты.
Все будет Украина!
Re: Давайте сравним
От: Ватакуси Россия  
Дата: 15.01.20 16:05
Оценка: 1 (1)
"Плохой питон" печатает отсутствующие данные из поступающего через stdin файла(см. http://files.rsdn.org/315/ts1.txt ):
import pandas as pd
import numpy as np
from click._compat import raw_input
from dateutil import parser


def calcMissing(readings:list) -> None:
    dates = []
    values = []
    missings = []
    for r in readings:
        timeStamp, val = r.split("\t")
        timeStamp = parser.parse(timeStamp)
        if val.startswith("Missing_"):
            val = np.nan
            missings.append(len(values))
        else:
            val = float(val)
        values.append(val)
        dates.append(timeStamp)
        
    df = pd.DataFrame({"dates": dates, "values": values})
    df = df.set_index("dates")
    df.interpolate(method="time", inplace=True, limit_direction="both")
    
    
    for missIndex in missings:
        print(df["values"].values[missIndex]) 
        

if __name__ == '__main__':
    readings_count = int(raw_input().strip())

    readings = []

    for _ in range(readings_count):
        readings_item = raw_input()
        readings.append(readings_item)

    calcMissing(readings)


Предлагайте как это сделать так же ненавязчиво в ц++ и иже с ним. Желательно, чтобы результат совпадал.

Ответы:

32.540000000000006
32.120000000000005
32.5525
29.38
29.286
28.884
30.512
29.648
29.59
30.95
31.22
31.4
29.69666666666667
29.473333333333333
29.634999999999998
29.356666666666666
29.7825
28.15
26.9275
27.375
Все будет Украина!
Отредактировано 15.01.2020 16:10 Ватакуси . Предыдущая версия . Еще …
Отредактировано 15.01.2020 16:08 Ватакуси . Предыдущая версия .
Отредактировано 15.01.2020 16:06 Ватакуси . Предыдущая версия .
Re[3]: Python в больших проектах
От: Anton Batenev Россия https://github.com/abbat
Дата: 15.01.20 18:42
Оценка: 1 (1)
Здравствуйте, Sharov, Вы писали:

S> 2)По идее стоит гугл, ну должен стоять. Гвидо там работал.


Гвидо покинул питон в 2018, гугл сделал ставку на го, который уже обошел питон по всем фронтам, кроме разве что ML да и то за счет инертности и числа либ. Лет 5 назад начинать проект на питоне было неплохим выбором, но надо вовремя уметь остановиться и принять, что py2 и py3 это разные языки. Плюс, кажется, последний собирается повторить судьбу Perl6.
github.com/abbat
Re[3]: Python в больших проектах
От: velkin Удмуртия http://blogs.rsdn.org/effective/
Дата: 15.01.20 10:21
Оценка: +1
Здравствуйте, kaa.python, Вы писали:

KP>В C++ и маленьких утилитах другая проблема. К тому времени когда ты соберешь в кучу все, что нужно для маленького проекта на C++, проект на Python уже будет радовать результатами.

KP>Можно-можно. Python по-умолчанию доступен много где.
KP>И в Python у тебя уже будет все что хочешь либо из коробки, либо путем добавления одной строчки в requirements.txt. Ну а как дела в C++ с подключением алгоритмов и библиотек, думаю, все и так знают.

Да, знаем.

Например, вот так:
LIBS += -lcryptopp

Или вот так:
LIBS += -lpoppler-qt4

Или даже так:
LIBS += -ldjvulibre

А здесь и вовсе каждый модуль отдельно:
LIBS += -lopencv_core -lopencv_imgproc -lopencv_highgui


Всё, я перетрудился добавляя сторонние библиотеки в свой проект, пойду отдохну. Другое дело, что не нужно заниматься популизмом. Или нужно?

Проблема здесь вовсе не в добавлении сторонних библиотек, а в том, что:

1) Открытый интерфейс этих библиотек не соответствует собственному восприятию понятий, причём в любом языке программирования и практически любой библиотеке алгоритмов. Потому когда кто-то говорит, я сел и написал за 5 минут на Python, и сторонние библиотеки подключил легко, а вот в C++ замучался, очень тяжело. Хочется спросить, а сколько времени ушло на изучение того же Python. То есть я зная как подключить библиотеки в C++ и чисто для примера не зная как это делается в Python, всё равно как бы должен считать, что в Python это всё проще.

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

Несколько раз перечитал твои комментарии, но так и не понял смысла. Я не утверждаю, что его там нет, это я просто не понял. Предположим у нас есть учебный пример алгоритма.

Название проекта: project_name
IDE: qt creator

Создаём папку project и копипастим два файла:
project_name
 project_name.pro
 project_name.cpp

project_name.pro
TARGET = project_name
TEMPLATE = app
CONFIG += console
CONFIG -= app_bundle qt
SOURCES += project_name.cpp

project_name.cpp
#include <iostream>
#include <cstdlib>
using namespace std;

int main()
{
    return EXIT_SUCCESS;
}


У нас появилась болванка. В ней можно кое-что поменять но не суть. Дальше размножаем её и в папке верхнего уровня создаём ещё один проект.
examples
 project_name
  project_name.pro
  project_name.cpp
 examples.pro

examples.pro
TEMPLATE = subdirs
SUBDIRS = \
project_name \ # наша болванка
project_name-01 \
project_name-02 \
project_name-03 \
project_name-04 \
project_name-05 \
project_name-06 \
project_name-07 \
project_name-08 \
project_name-09 \
project_name-10


Но вот вопрос, зачем было называть файл C++ project_name. А затем, чтобы положить в эту же папку исходники других языков. Если бы это был hello_world:

assembler
.data
msg:
  .ascii "Hello, world!\n"
  .set len, . - msg

.text

.globl main
main:
  # write
  mov $4,   %eax
  mov $1,   %ebx
  mov $msg, %ecx
  mov $len, %edx
  int $0x80

  # exit
  mov $1,   %eax
  xor %ebx, %ebx
  int $0x80


bash
#!/bin/bash
echo "Hello, world!"


c++
#include <iostream>
#include <cstdlib>
using namespace std;

int main()
{
    cout << "Hello, world!" << endl;
    return EXIT_SUCCESS;
}


go
package main;

import "fmt"

func main() {
fmt.Println("Hello, world!")
}


Java
public class HelloWorld {
    public static void main(String[] args) {
        System.out.println("Hello, world!");
    }
}


pascal
begin
    writeln('Hello, world!');
end.


php
<?php
echo "Hello, world!";
?>


prolog
:- initialization hello_world, halt.

hello_world :-
    write('Hello, World!'), nl.


python
print("Hello, world!")


ruby
puts "Hello, World!"


Файлы могли выглядеть бы так:
hello_world.s
hello_world.sh
hello_world.cpp
hello_world.go
HelloWorld.java
hello_world.lua
hello_world.pas
hello_world.php
hello_world.pl
hello_world.py
hello_world.rb


Теперь что касается запусков, оставим пока IDE.

C++ компиляция
g++ hello_world.cpp -o hello_world_cpp

C++ запуск
./hello_world_cpp


Теперь Python.
python hello_world.py


Остальные языки нас вроде бы как не интересуют, но чисто для примера.

Assembler компиляция
gcc -m32 hello_world.s -o hello_world_asm

Assembler запуск
./hello_world_asm


Bash запуск
sh hello_world.sh


Go запуск
go run hello_world.go

или

Go компиляция
go build hello_world.go

Go запуск
./hello_world


Java компиляция
javac HelloWorld.java

Java запуск
java HelloWorld


Lua запуск
lua hello_world.lua


Pascal компиляция
fpc hello_world.pas

Pascal запуск
./hello_world


Php запуск
php hello_world.php


Prolog запуск
swipl -q -l hello_world.pl


Ruby запуск
ruby hello_world.rb


Есть различия в точке доступа в приложение, но вот прямо принципиальной разницы, почему Python (а мне из скриптовых вообще-то нравится лишь Lua) не вижу. Тот же Bash через аргументы командной строки использует другие программы как библиотеки алгоритмов. Но разве это его уникальное свойство.

К тому же, выражение на Python всё есть, но откуда оно там взялось. Ах, да, большая часть это вызовы на библиотеки алгоритмов C/C++. Это логично, потому что скрипты в том числе для этого и созданы. Другое дело, что это не делает скрипты принципиально лучше, ни для разработки, ни для прототипирования. Дописать функционал, которого нет в основной программе, это да, а вот когда пишешь эту самую программу не получаешь никаких преимуществ.

examples
 project_name
  project_name.pro
  project_name.cpp
  project_name.s
  project_name.sh
  project_name.cpp
  project_name.go
  ProjectName.java
  project_name.lua
  project_name.pas
  project_name.php
  project_name.pl
  project_name.py
  project_name.rb
 examples.pro


Ладно, это всё были хелло ворлды. Если не жалко времени приведи конкретный "внушительный" пример, чтобы я мог посмотреть на код и сказать, — "О, Python это круто, а вот тот же самый проект или прототип на C++ полное говно".
Re[5]: Python в больших проектах
От: velkin Удмуртия http://blogs.rsdn.org/effective/
Дата: 15.01.20 11:23
Оценка: +1
Здравствуйте, Igore, Вы писали:

V>>Например, вот так:

V>>
V>>LIBS += -lcryptopp
V>>

I>А так же LIB_PATH, INCLUDE_PATH, а, библиотеку же еще скачать и собрать надо, и хранить, и ключи компиляции/линковки должны совпадать, под Linux еще RPATH или LD_LIBRARY_PATH + возможные зависимости. Еще и инсталятор нужно, под Windows хоть из той же папки грузится, тут хоть архив на первое время можно сделать.

Если вот это файл проекта Qt:

project_name.pro
TARGET = project_name
TEMPLATE = app
CONFIG += console
CONFIG -= app_bundle qt
SOURCES += project_name.cpp


И нужно подключить, например crypto++, то в том же Debian
apt install libcrypto++-dev


И проект соответственно будет:

project_name.pro
TARGET = project_name
TEMPLATE = app
CONFIG += console
CONFIG -= app_bundle qt
SOURCES += project_name.cpp
LIBS += -lcryptopp # подключили


А ещё есть вот такой пакет python-pycryptopp.
apt install python-pycryptopp

PyCryptopp is a set of Python wrappers for a few of the best crypto algorithms
from the Crypto++ library (including SHA-256, AES, RSA signatures and Elliptic
Curve DSA signatures).


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

I>Именно что хелло ворлды, хорошо, прототип, отслеживать выложеную в интеренете БД в формате ACCESS, после скачать и обновить данные в твоей локальной postgresql базе, на python-e будет в разы проще сделать. А для C++ можешь попробовать для разных системы прикинуть какие библиотеки тебе понадобятся для реализации этого несложного приложения.


Тоже самое можно сделать и для C++. Python это обёртки, обёртки и ещё раз обёртки. Возможно меня здесь уже записали в противники Python, но я просто не вижу разницы запускать напрямую или обёрткой. Причём от проблемы версий библиотек алгоритмов мы никуда не ушли.
Re[2]: Mercurial не нужен
От: $$ Австралия жж
Дата: 15.01.20 12:17
Оценка: -1
Здравствуйте, kov_serg, Вы писали:

_>

_># Mercurial will never work on Python 3 before 3.5 due to a lack
_># of % formatting on bytestrings, and can't work on 3.6.0 or 3.6.1
_># due to a bug in % formatting in bytestrings.
_># We cannot support Python 3.5.0, 3.5.1, 3.5.2 because of bug in
_># codecs.escape_encode() where it raises SystemError on empty bytestring


subj
Re[2]: Python в больших проектах
От: Pzz Россия https://github.com/alexpevzner
Дата: 15.01.20 13:47
Оценка: +1
Здравствуйте, Erop, Вы писали:

E>Просто P2 и P3 шибко разные. Первый про списки, а второй про итераторы, например.

E>В целом мне лично не понятно, зачем вообще переписывать что-то большое с P2 на P3, а не на какой-нибудь более типизированный язык...

Не очень понятно, почему бы на P2 и не осталься. Ясно же, что это два достаточно разных языка, и P3 никогда не вытеснит P2, они так и будут вечно сосуществовать.
Re[7]: Python в больших проектах
От: velkin Удмуртия http://blogs.rsdn.org/effective/
Дата: 15.01.20 14:22
Оценка: :)
Здравствуйте, Nuzhny, Вы писали:

N>1. Разработчики Qt отказываются от qmake, начиная с Qt 6.

N>2. Разработчики Qt отказываются от своей же Qbs, начиная с Qt 6.
N>Смысл стал виден? Рискуешь оказаться в положении разработчиков Mercurial.

Самое смешное, что это был не просто Qt, а Qt 4.8.7, хотя это и не очевидно из кода. Меня в любом случае это не касается и мне всё равно, что там сделают в новой версии. Что касается C++, то мне думается нужно уходить к истокам, то есть к Бьерну Страуструпу, книга "Язык программирования C++ — очередное издание". У каждого языка есть свой создатель, например, для Lua это Роберту Иерузалимски с книгой "Программирование на языке Lua" и так далее.

В языках программирования важна изначальная идеология, а она во многих проектах была потеряна. Например, C++ задумывался как язык в котором весь код разделён на небольшие независимые части, а лишнее вынесено из классов в функции поддержки (helper functions) и тому подобное. При компиляции должен получаться максимально быстрый и компактный код. Но в результате имеем божественные объекты, в коде понапиханы макросы, не функциональный код (АОП) мешает анализировать алгоритм, ещё и чужие библиотеки, которые переписывают как вздумается.

Чтобы начать деградировать нужно сначала спрогрессировать, а у нас денег нет.


Кто виноват и что делать? Виноват ли язык программирования, а может это программисты так пишут и потом распространяют.
Re[8]: Python в больших проектах
От: Ватакуси Россия  
Дата: 15.01.20 15:38
Оценка: +1
N>>>Я пару раз попадал на это
В>>На ц++ хелл? Или откатывание пипа?

N>На откатывание пипа. Вручную подбирал версию пипа и библиотек.

Почти всегда (в моей вселенной так вообще всегда), либо последняя версия пипа или нужно что-то с ц++ библиотеками чудить.

Откатывать назад не очень понятно зачем, старый пип же с новыми библиотеками скорее всего не заработает.
Все будет Украина!
Re[12]: Python в больших проектах
От: Ватакуси Россия  
Дата: 15.01.20 15:41
Оценка: +1
KP>>Это просто больно читать... virtualenv, venv море других. Просто не надо валить всё в системные библиотеки Питона и всё будет хорошо.

N>Я же как раз и отвечал, что virtualenv использую. Это работает, когда имеешь дело с одним репозиторием на Гитхабе. Но когда надёргиваешь код из разных источников, то всё ломается и начинаются пляски с бубном. Кажется, что большую программу на Питоне просто так вообще не написать, поэтому и стали популярными Докеры и микросервисы — не только из-за масштабируемости, но и из-за того, что всё работает само по себе с кучей разных библиотек разных версий. Описанная мной проблема как раз и была в отдельном env.


Когда версии гвоздями прибиты, то такое вообще не надо брать. На крайняк, качнуть и исправить на последнии версии всего, чего только можно.
Докер для другого используют на самом деле, почти всегда именно из-за ц++ хэла. Если ещё из-за каких проблем окружения.
Все будет Украина!
Re[2]: Python в больших проектах
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 15.01.20 19:27
Оценка: +1
Здравствуйте, Erop, Вы писали:

E>Просто P2 и P3 шибко разные. Первый про списки, а второй про итераторы, например.

E>В целом мне лично не понятно, зачем вообще переписывать что-то большое с P2 на P3, а не на какой-нибудь более типизированный язык...

Затем, что для обычного проекта такой переход на Py3 раз в 10-100 дешевле переписки на совсем другой язык.
The God is real, unless declared integer.
Re[2]: Давайте сравним
От: Буравчик Россия  
Дата: 15.01.20 19:35
Оценка: +1
Здравствуйте, Ватакуси, Вы писали:

В>"Плохой питон" печатает отсутствующие данные из поступающего через stdin файла(см. http://files.rsdn.org/315/ts1.txt ):


Не понравилось, что используются циклы, а также сторонние библиотеки. Можно обойтись без них. Поэтому еще вариант на питон:
import sys
from itertools import islice
from typing import List

import numpy as np
import pandas as pd


def calc_missing(lines: List[str]) -> np.ndarray:
    # формируем dataset из строк
    data = [line.split('\t') for line in lines]
    df = pd.DataFrame(data, columns=['date', 'value'])

    # запоминаем индексы missing-строк для последующего отбора
    missings_indexes = df.value.str.startswith('Missing_')

    # интерполяция
    df.loc[missings_indexes, 'value'] = np.nan
    df['value'] = df.value.astype(float)
    df['date'] = pd.to_datetime(df.date)
    df = df.set_index('date').interpolate(method="time", limit_direction="both").reset_index()
    return df.value.values[missings_indexes]


def main():
    count = int(sys.stdin.readline())
    lines = list(islice(sys.stdin, count))
    missing = calc_missing(lines)
    print(missing)


if __name__ == '__main__':
    main()
Best regards, Буравчик
Отредактировано 15.01.2020 19:44 Буравчик . Предыдущая версия .
Re[3]: Python в больших проектах
От: Masterspline  
Дата: 15.01.20 22:07
Оценка: +1
S>1)было 2.*, появилось 3.* Две реализации, выбирай не хочу.

Python 2 перестанет поддерживаться с этого года. Уже сейчас его почти отовсюду выпилили (даже из Debian), он остался только в RedHat/CentOS.
Версия под 3.* гарантированно не работает (работает с ошибками) под большинством версий 3.*. После перехода на 3.* недоделки придется выгребать лопатой, а VCS должна быть такой же надежной, как и файловая система. Так что сейчас разумный человек не станет пользоваться ни той ни другой версией.

S>2)По идее стоит гугл, ну должен стоять. Гвидо там работал.


Гвидо ушел из Гугла довольно давно (лет 5-8 навскидку). Даже разработку Python он уже не возглавляет (он теперь рядовой разработчик). У тебя там что совсем интернета нет?

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

В этом плане cvs, svn, hg стоят на одной полке антипаттернов разработки. Можно взять git и делать все то же самое и ни у кого не возникнет вопросов. А можно взять hg и у каждого пришедшего в проект возникнет вопрос: "зачем".

P.S. Существующая инфраструктура, если она крутится вокруг hg, вполне переделывается на git и другие современные инструменты, которые его поддерживают.
Отредактировано 16.01.2020 2:38 Ssd13 . Предыдущая версия .
Re[3]: Python в больших проектах
От: Erop Россия  
Дата: 16.01.20 05:15
Оценка: +1
Здравствуйте, netch80, Вы писали:

E>>В целом мне лично не понятно, зачем вообще переписывать что-то большое с P2 на P3, а не на какой-нибудь более типизированный язык...


N>Затем, что для обычного проекта такой переход на Py3 раз в 10-100 дешевле переписки на совсем другой язык.

А вообще не переписывать -- ещё дешевле... Зачем вообще P2 менять на P3? Это, примерно, как переписать что-то с С++ на D, только ещё более бессмысленно...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[5]: Python в больших проектах
От: Mamut Швеция http://dmitriid.com
Дата: 16.01.20 10:09
Оценка: +1
Б>Язык продолжает развиваться, не ломая обратную совместимость. Все в порядке

Мнэээ. Даже в оригинальном сообщении в статье говорится прямым текстом: было сломано дофига обратной совместимости. Настолько, что под давлением коммьюнити некоторые изменения постепенно откатывали назад. Но настолько медленно, что крупные проекты стало возможно переводить только начная с Питона 2.7 и 3.5, не раньше.


dmitriid.comGitHubLinkedIn
Re[4]: Давайте сравним
От: Буравчик Россия  
Дата: 16.01.20 10:28
Оценка: +1
Здравствуйте, Mamut, Вы писали:


Б>>Не понравилось, что используются циклы, а также сторонние библиотеки. Можно обойтись без них.

Б>>
Б>>import numpy as np
Б>>import pandas as pd
Б>>


M>


Это либы — норма для DS. А вот click — используется не всегда (не часто), тем более субпакет compat.
dateutil тоже, т.к. pandas часто имеет нужный функционал.

Читай: "можно обойтись без циклов и уменьшить количество библиотек".
Best regards, Буравчик
Re[3]: Давайте сравним
От: Ватакуси Россия  
Дата: 16.01.20 11:07
Оценка: +1
A>Простая линейная интерполяция с такими же ошибками. Не знаю, что требуется делать, если отсутствуют крайние значения, поэтому проигнорировал.
Скажем честно выглядит сильно тяжелее. И не работает с отсутствующими крайними значениями, как ты и сказал.
Все будет Украина!
Re[3]: Python в больших проектах
От: novitk США  
Дата: 16.01.20 23:01
Оценка: :)
Здравствуйте, Nuzhny, Вы писали:

N>>Заголовок не соответствует содержанию. Чувак из меркуриала жалуется на переход py2->py3, а не на динамику. Представь себе C++ теряет обратную совместимость и остается без поддержки и всем предлагается перейти на С+++? Сильно тебе статика поможет?

N>Да, конечно. Компилятор + статический анализатор кода (он по-умолчанию мощнее питоновского) найдут срау же множество проблем. Ты не знал?!!
Статический анализатор кода даст тебе некоторые, весьма слабые в случае Java, гарантии, но код на другом языке писать не будет.

N>>Ключевой система по расчету риска для двух инвест.банка написана на Питоне (>1мм LoC) на который перешли со .... Smalltalk-a.

N>Сам факт, что это написано на Питоне не говорит о его плюсе. Возможно, что написав это на Java плюсов у системы было бы больше.
Системы написанные на Яве проиграли в конкурентной борьбе.

N>К тому же, была бы возможность использовать разные языки (ту же Scala) для разных задач в рамках одной платформы.

Ты так говоришь, как будто зоопарк это нечто хорошее.

N>В какой продуктивности? Пишется медленнее? Работает медленнее? А как дела с процентом багов в коде?

Пишется медленее. Ты преувеличиваешь способность статического анализа по снижению процента багов. Большинство ошибок, которые выявляет широко используемые статические языки, до продакшена у питона тоже не доходят.
Re[2]: Python в больших проектах
От: Ops Россия  
Дата: 18.01.20 13:30
Оценка: +1
Здравствуйте, Erop, Вы писали:

E>Просто P2 и P3 шибко разные. Первый про списки, а второй про итераторы, например.

E>В целом мне лично не понятно, зачем вообще переписывать что-то большое с P2 на P3, а не на какой-нибудь более типизированный язык...

Я так понимаю, у них с поддержкой даже одной версии неочень
Автор: Vain
Дата: 16.01.20
, а 2 они просто не тянут.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re[9]: Python в больших проектах
От: 13akaEagle Россия  
Дата: 20.01.20 14:52
Оценка: +1
Здравствуйте, Pzz, Вы писали:

Pzz>pip install гадит в какую-то свою кучу, общую для всех, а Go управляет зависимостями для каждого проекта отдельно и независимо от прочих проектов.

Для питона принято создавать виртуальное окружение, наружу пакеты не утекают.
Re: Python в больших проектах
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 15.01.20 02:12
Оценка:
Здравствуйте, Nuzhny, Вы писали:

N>Удивительное дело, что такой большой проблемой является переход на новую версию языка, которая появилась уже более 10 лет назад.

N>Спрашивается: нахер оно тогда надо, писать нетленку на динамических языках? Только прототипы! Тут же и тесты не особо помогут, потому что и их надо переписывать. Я раньше как-то не понимал всей глубины проблемы, но сейчас удивляюсь, как вообще можно что-то большое делать на динамике. Плюсовые и шарповые проекты не всегда легко, но достаточно уверенно переползают со стандарта на стандарт, на новые компиляторы и платформы. И 100% покрытия тестами в них нет, но кажется, что само переползание чаще лечит прошлые баги, чем добавляет новых.
N>Вот, просто ужаснулся и захотелось поделиться.

Сначала хотел написать что полностью поддерживаю, но потом передумал. С одной стороны ты прав, писать на динамике что-то кроме прототипов и тестов зачастую себе дороже. С другой стороны, сейчас динамика как бы и не совсем динамика – со всех сторон проверка типов, аннотации, спеки... С другой стороны, писать приложение бодро оперирующее данными на динамике всё же удобнее и быстрее. Динамика многое упрощает, просто необходимо иметь что-то еще, как например функциональную парадигму.
Например мой текущий проект использует Elixir и на любом другом языке с которыми я работал (разве что кроме Clojure) его было бы куда более тяжело развивать. Но у нас классический бэкенд с кучей запросов к базе и отсутствием состояний.
Так что, задача важна, был бы Меркуриал на C++ (а какой был выбор был в 2005?), то были бы просто проблемы другого рода, не менее злобные. Если же говорить про миграцию C++ проектов, то у меня как-то ушло около 3-х месяцев перевести кодовую базу KAV на C++11. Правда надо признать, после этого никаких проблем связанных с миграцией на новый стандарт не было.
Re: Python в больших проектах
От: $$ Австралия жж
Дата: 15.01.20 02:43
Оценка:
Здравствуйте, Nuzhny, Вы писали:

ЧСХ при определенной аккуратности с скобками и неиспользовании 3-only конструкций, скрипт работал под 2.7 и под 3.5.
Re[2]: Python в больших проектах
От: CreatorCray  
Дата: 15.01.20 04:37
Оценка:
Здравствуйте, kov_serg, Вы писали:

_>

_># Mercurial will never work on Python 3 before 3.5 due to a lack
_># of % formatting on bytestrings, and can't work on 3.6.0 or 3.6.1
_># due to a bug in % formatting in bytestrings.
_># We cannot support Python 3.5.0, 3.5.1, 3.5.2 because of bug in
_># codecs.escape_encode() where it raises SystemError on empty bytestring


Сурово!
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Re[3]: Python в больших проектах
От: Sheridan Россия  
Дата: 15.01.20 07:06
Оценка:
Здравствуйте, Privalov, Вы писали:

S>> Но некоторые личности до сих пор мне это вспоминают

P>В печку же...

Да-да, ты в том числе
Matrix has you...
Re: Python в больших проектах
От: vsb Казахстан  
Дата: 15.01.20 07:19
Оценка:
Некоторые части кода удобно писать на динамике. Не понимаю, почему так мало статических языков это позволяют. Кроме C# нигде не видел dynamic. В той же Java — пишешь взаимодействие через JSON какой-нибудь: либо описывай весь протокол классами, втискивая его в прокрустово ложе маппера и это не факт, что всегда получится; либо пиши кошмарный код с Map<?, ?> и List<?>. Куда проще было бы сказать dynamic в этом случае, пускай "под капотом" и были бы ровно те же Map-ы, но код был бы куда проще.
Re[2]: Python в больших проектах
От: Privalov  
Дата: 15.01.20 08:26
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>Куда проще было бы сказать dynamic в этом случае, пускай "под капотом" и были бы ровно те же Map-ы, но код был бы куда проще.


С dynamic есть одна проблема. Ими частенько злоупотребляют. Мне вот по наследству досталась некая утилита. Автор для удобства использовал dynamic и рефлексию. А я внезапно выяснил, что программа эта свою конфигурацию считывает вовсе не из конфига, а из весьма неожиданных мест. И как это теперь починить, я не очень представляю. Не, я, конечно, костыль поставил, и оно работает. Но как бы этот костыль в недалеком будущем в грабли не превратился.
Re[2]: Python в больших проектах
От: rudzuk  
Дата: 15.01.20 08:44
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>Кроме C# нигде не видел dynamic.


В Delphi.
avalon/2.0.6
Re: Python в больших проектах
От: Ватакуси Россия  
Дата: 15.01.20 09:07
Оценка:
N>Новость про Mercurial.
Неизвестно какое там вообще качество кода и качество людей.

N>Удивительное дело, что такой большой проблемой является переход на новую версию языка, которая появилась уже более 10 лет назад.

N>Спрашивается: нахер оно тогда надо, писать нетленку на динамических языках? Только прототипы! Тут же и тесты не особо помогут, потому что и их надо переписывать. Я раньше как-то не понимал всей глубины проблемы, но сейчас удивляюсь, как вообще можно что-то большое делать на динамике. Плюсовые и шарповые проекты не всегда легко, но достаточно уверенно переползают со стандарта на стандарт, на новые компиляторы и платформы. И 100% покрытия тестами в них нет, но кажется, что само переползание чаще лечит прошлые баги, чем добавляет новых.
N>Вот, просто ужаснулся и захотелось поделиться.
Так либо трудность разработки, либо динамика. И там и там плюсы и минусы.

PS: Большие проекты вполне пишутся, нужны только бабки и люди. Собственно, как везде.
Все будет Украина!
Re[5]: Python в больших проектах
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 15.01.20 09:27
Оценка:
Здравствуйте, Ватакуси, Вы писали:

M>>Ага. pip install bl-bla. Ой, не работает. Гуглим. А-а-а, надо откатить pip на конкретную версию, иначе эту хрень не поставить

В>Никогда не встречал. Может не компилироваться из-за ц++ хелла на твоей машине, это да. Раза 3 или 4 приходилось долго танцевать.

Я пару раз попадал на это
Re[6]: Python в больших проектах
От: Ватакуси Россия  
Дата: 15.01.20 09:54
Оценка:
M>>>Ага. pip install bl-bla. Ой, не работает. Гуглим. А-а-а, надо откатить pip на конкретную версию, иначе эту хрень не поставить
В>>Никогда не встречал. Может не компилироваться из-за ц++ хелла на твоей машине, это да. Раза 3 или 4 приходилось долго танцевать.

N>Я пару раз попадал на это

На ц++ хелл? Или откатывание пипа?
Все будет Украина!
Re[7]: Python в больших проектах
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 15.01.20 09:57
Оценка:
Здравствуйте, Ватакуси, Вы писали:

N>>Я пару раз попадал на это

В>На ц++ хелл? Или откатывание пипа?

На откатывание пипа. Вручную подбирал версию пипа и библиотек.
Re[8]: Python в больших проектах
От: Masterspline  
Дата: 15.01.20 10:25
Оценка:
N>На откатывание пипа. Вручную подбирал версию пипа и библиотек.

Я на Python не писал ничего серьезного, но давно понял, что любой проект сложнее скрипта из одного файла нужно начинать с установки и настройки virtual environment. Неужели кто-то делает по-другому...
Re: Python в больших проектах
От: MasterZiv СССР  
Дата: 15.01.20 11:40
Оценка:
Здравствуйте, Nuzhny, Вы писали:

N>Спрашивается: нахер оно тогда надо, писать нетленку на динамических языках? Только прототипы! Тут же и тесты не особо помогут, потому что и их надо переписывать. Я раньше как-то не понимал всей глубины проблемы,


Ты и сейчас её не понимаешь.
ОНИ СЧИТАЮТ, ЧТО ЕСЛИ ОНИ НЕ ПОДНИМУТ ВСЁ ЭТО ГОВНО, КОМУ-ТО БУДЕТ ХУЖЕ!
вот в чём проблема.
Re[10]: Python в больших проектах
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 15.01.20 12:12
Оценка:
Здравствуйте, Nuzhny, Вы писали:

N>Я также делаю, но оно же не обязательно будет работать. Ты ставишь requirements для одного проекта, пишешь код, например, сервера. Потом хочешь сделать, чтобы он распознавал котиков на фотках. Находишь предобученную модель, подключаешь tensorflow, а он не работает. Ему нужен другой python, более древний. И какой-нибудь другой protobuf. Или numpy. Потом выясняется, что это старая версия или версия, которая требует строго определённые версии пакетов, ни больше, ни меньше. Не случайно сейчас самые популярные репозитории начинают раздел Install со слов: "Скачайте такой-то Докер..." Как раз потому что в версиях Питона и библиотек разброд и шатание и не так просто подбирать рабочие комбинации для разных библиотек.


Это просто больно читать... virtualenv, venv море других. Просто не надо валить всё в системные библиотеки Питона и всё будет хорошо.
Re[4]: Python в больших проектах
От: Mamut Швеция http://dmitriid.com
Дата: 15.01.20 12:14
Оценка:
V>C++ компиляция
V>
V>g++ hello_world.cpp -o hello_world_cpp
V>

V>C++ запуск
V>
V>./hello_world_cpp
V>


V>Теперь Python.

V>
V>python hello_world.py
V>



Это должно было показать, что нет никакой разницы между питоном и C++, что ли?

C++: создать сборочный файл, запустить компиляцию, запустить файл
Python: python файл_в_котором_кот.py



dmitriid.comGitHubLinkedIn
Re[11]: Python в больших проектах
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 15.01.20 12:18
Оценка:
Здравствуйте, kaa.python, Вы писали:

KP>Это просто больно читать... virtualenv, venv море других. Просто не надо валить всё в системные библиотеки Питона и всё будет хорошо.


Я же как раз и отвечал, что virtualenv использую. Это работает, когда имеешь дело с одним репозиторием на Гитхабе. Но когда надёргиваешь код из разных источников, то всё ломается и начинаются пляски с бубном. Кажется, что большую программу на Питоне просто так вообще не написать, поэтому и стали популярными Докеры и микросервисы — не только из-за масштабируемости, но и из-за того, что всё работает само по себе с кучей разных библиотек разных версий. Описанная мной проблема как раз и была в отдельном env.
Re[3]: Mercurial не нужен
От: Skorodum Россия  
Дата: 15.01.20 12:19
Оценка:
Здравствуйте, $$, Вы писали:

$>subj
Да пусть свой век доживает, потом само отомрет.
Re[5]: Python в больших проектах
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 15.01.20 12:20
Оценка:
Здравствуйте, kaa.python, Вы писали:

KP>Отвлеченный вопрос, как ты находишь время такие простыни ответов писать? Их даже читать долго же


Ну, на современном CMake + vcpkg не сложнее, а то и проще. Оно пока ещё не такое гибкое как pip, но уже ближе к нему, чем голый CMake или qmake
Re[12]: Python в больших проектах
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 15.01.20 12:44
Оценка:
Здравствуйте, Nuzhny, Вы писали:

N>Я же как раз и отвечал, что virtualenv использую. Это работает, когда имеешь дело с одним репозиторием на Гитхабе. Но когда надёргиваешь код из разных источников, то всё ломается и начинаются пляски с бубном. Кажется, что большую программу на Питоне просто так вообще не написать, поэтому и стали популярными Докеры и микросервисы — не только из-за масштабируемости, но и из-за того, что всё работает само по себе с кучей разных библиотек разных версий. Описанная мной проблема как раз и была в отдельном env.


Ну, разве что это особенность ML. Я довольно много делал проектов на Python и с описанным сталкивался только по молодости и глупости, когда про venv не знал
Re[6]: Python в больших проектах
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 15.01.20 12:57
Оценка:
Здравствуйте, Nuzhny, Вы писали:

N>Ну, на современном CMake + vcpkg не сложнее, а то и проще. Оно пока ещё не такое гибкое как pip, но уже ближе к нему, чем голый CMake или qmake


Сложнее всё-же. Во-первых, телодвижений больше чем с Python, хотя и не так много как было раньше. Во-вторых, к проекту нужны тесты, тут еще больше сложностей. В-третьих, если (когда) проект вырастет, CMake превратится в ад. В-четвертых, когда проект вырастет, с большой вероятностью о предсобранных в vcpkg пакетах придется забыть.

C++ зык прекрасный, но вот сборочно-тестовая-деплойная инфраструктура, мягко говоря, оставляет желать лучшего.
Re[5]: Python в больших проектах
От: velkin Удмуртия http://blogs.rsdn.org/effective/
Дата: 15.01.20 13:18
Оценка:
Здравствуйте, kaa.python, Вы писали:

KP>Уверен что знаешь? С чего вдруг на машине должен быть QMake (у меня вообще никогда не было)? Показал бы уж как всё легко и просто, ну и конечно кроссплатформенно, на Makefile.


Я же написал так сказать ручной запуск из командной строки для gcc (g++). CMake применять не вижу смысла, так как пользуюсь Qt Creator, но замечу, что CMake, что QMake везде ручной набор. И касательно систем сборок это дело десятое, их довольно много. Однако никто не мешает добавить тем же способом то, что нужно, тот же Makefile, и даже не обязательно под этим именем. Иными словами идея не только в том, чтобы создавать разные файлы для систем сборок одного языка программирования, так же параллельно можно добавить проекты для других языков, а то и вовсе объединить, пусть даже без прямой поддержки IDE.

project_name.pro
TARGET = project_name
TEMPLATE = app
CONFIG += console
CONFIG -= app_bundle qt
SOURCES += project_name.cpp
OTHER_FILES += project_name.py project_name.lua # ... и так далее

KP>Отвлеченный вопрос, как ты находишь время такие простыни ответов писать? Их даже читать долго же

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

https://sysdev.me/rsdn-the-end/

Времени катастрофически ни на что не хватает, а на ближайший год очень серьезные планы. Одним из главных бессмысленных пожирателей свободного времени, до вчерашнего дня был РСДН, всё остальное давно “похерил”.
Поразмыслив на тему планирования времени, временно ушел оттуда, самозабанившись на 1 год. Жалко, конечно, но реально нужно достать еще свободного времени.


Да, я и на этот блог нашёл время сколько-то лет назад и не только. У кого-то мало времени, у кого-то много, но в любом случае люди движутся к смерти. Каждый сам определяет себе приоритеты.

Мысли:

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

Но этого не будет.
Re[6]: Python в больших проектах
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 15.01.20 13:29
Оценка:
Здравствуйте, velkin, Вы писали:

V>Я же написал так сказать ручной запуск из командной строки для gcc (g++). CMake применять не вижу смысла, так как пользуюсь Qt Creator


1. Разработчики Qt отказываются от qmake, начиная с Qt 6.
2. Разработчики Qt отказываются от своей же Qbs, начиная с Qt 6.

To summarize the key points:
— Qbs will continue to be supported until end of 2019
— Last Qbs release will come out in April 2019
— Qbs continues to work with upcoming Qt Creator 4.8 and Qt Creator 4.9
— Qbs library and tools will be available under Qt Project for possible further development by the community
— Support for qmake will continue unaffected
— Support for CMake will improve
— Longer term, we plan to switch to CMake for building Qt itself
— CMake support in Qt Creator will be further improved


Смысл стал виден? Рискуешь оказаться в положении разработчиков Mercurial.
Re[2]: Python в больших проектах
От: Pzz Россия https://github.com/alexpevzner
Дата: 15.01.20 13:37
Оценка:
Здравствуйте, kov_serg, Вы писали:

_>

_># Mercurial will never work on Python 3 before 3.5 due to a lack
_># of % formatting on bytestrings, and can't work on 3.6.0 or 3.6.1
_># due to a bug in % formatting in bytestrings.
_># We cannot support Python 3.5.0, 3.5.1, 3.5.2 because of bug in
_># codecs.escape_encode() where it raises SystemError on empty bytestring


Гнилые отмазки какие-то. Форматинг можно и переписать, в конце концов. Или перестать им пользоваться. Вряд ли там больше нескольких мест, где % используется с байтовыми строками.
Re[3]: Mercurial не нужен
От: Pzz Россия https://github.com/alexpevzner
Дата: 15.01.20 13:38
Оценка:
Здравствуйте, $$, Вы писали:

$>subj

Нужен. Мне нужен.
Re[4]: Python в больших проектах
От: Pzz Россия https://github.com/alexpevzner
Дата: 15.01.20 13:43
Оценка:
Здравствуйте, velkin, Вы писали:

V>Например, вот так:

V>
V>LIBS += -lcryptopp
V>


Это все хорошо, когда нужная тебе библиотека есть в виде стандартного пакета для твоего дистрибутива твоей любимой ОС. А когда нету, начинается беда.
Re[3]: Python в больших проектах
От: Erop Россия  
Дата: 15.01.20 14:13
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>Не очень понятно, почему бы на P2 и не осталься. Ясно же, что это два достаточно разных языка, и P3 никогда не вытеснит P2, они так и будут вечно сосуществовать.


Я согласен, что переписывать вообще, скорее всего, не надо. Но если уж переписывать зачем-то, то уж точно не на P3. На этом пути что-то выиграть нереально
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[3]: Python в больших проектах
От: Mamut Швеция http://dmitriid.com
Дата: 15.01.20 14:44
Оценка:
Pzz>Не очень понятно, почему бы на P2 и не осталься. Ясно же, что это два достаточно разных языка, и P3 никогда не вытеснит P2, они так и будут вечно сосуществовать.

Поддержка питона 2.7 заканчивается в этом году.


dmitriid.comGitHubLinkedIn
Re[4]: Python в больших проектах
От: Pzz Россия https://github.com/alexpevzner
Дата: 15.01.20 14:58
Оценка:
Здравствуйте, Mamut, Вы писали:

Pzz>>Не очень понятно, почему бы на P2 и не осталься. Ясно же, что это два достаточно разных языка, и P3 никогда не вытеснит P2, они так и будут вечно сосуществовать.


M>Поддержка питона 2.7 заканчивается в этом году.


Ну значит, его будет поддерживать RedHat или Canonical. Скажут нехорошее слово, и будут поддерживать.
Re[5]: Python в больших проектах
От: Mamut Швеция http://dmitriid.com
Дата: 15.01.20 15:07
Оценка:
M>>Поддержка питона 2.7 заканчивается в этом году.
Pzz>Ну значит, его будет поддерживать RedHat или Canonical. Скажут нехорошее слово, и будут поддерживать.

Завязывать проект на «может быть кто-то начнет поддерживать питон 2.x» немного нелогично, не находишь?


dmitriid.comGitHubLinkedIn
Re[6]: Python в больших проектах
От: Pzz Россия https://github.com/alexpevzner
Дата: 15.01.20 15:09
Оценка:
Здравствуйте, Mamut, Вы писали:

M>>>Поддержка питона 2.7 заканчивается в этом году.

Pzz>>Ну значит, его будет поддерживать RedHat или Canonical. Скажут нехорошее слово, и будут поддерживать.

M>Завязывать проект на «может быть кто-то начнет поддерживать питон 2.x» немного нелогично, не находишь?


Завязывать новый проект не стоит. Но на 2-м питоне уже написано некоторое количество ценных проектов — тот же меркурий.
Re[7]: Python в больших проектах
От: Mamut Швеция http://dmitriid.com
Дата: 15.01.20 15:14
Оценка:
Pzz>Завязывать новый проект не стоит. Но на 2-м питоне уже написано некоторое количество ценных проектов — тот же меркурий.

Ну то есть ценный проект меркурий должен был сказать «авось в 2020-м кто-то наконец-то появится и начент поддержку питона 2.х. А то в 2014-м объявили, что поддержка закончится в 2020-м, за шесть лет так никто и не объявился, а вот в 2020-м точно наверняка кто-то возьмет и продолжит поддержку». Так, что ли?


dmitriid.comGitHubLinkedIn
Re[2]: Python в больших проектах
От: Ватакуси Россия  
Дата: 15.01.20 15:49
Оценка:
N>На питоне пишутся огромные систему. Ключевой система по расчету риска для двух инвест.банка написана на Питоне (>1мм LoC) на который перешли со .... Smalltalk-a. Сейчас я работаю с такой же системой в еще одном инвест банке(все три входят в первую пятерку в мире), где вместо Питона решили использовать Скалу. Результат в продуктивности имхо сильно хуже чем с Питоном, хотя это пожалуй самый продвинутый язык в относительном мэйнстриме. Поэтому кванты потихоньку саботируют и пишут на питончике, хотя в IT конечно так сделать наверно не дадут.

Скала была модно год-два назад, щас кол-во работы упало экспоненциально по моим наблюдениям.
В интернетах пишут:

Scala offers very limited community presence.
It is not the easily adaptable language.
Offers very limited backward compatibility
Все будет Украина!
Re[2]: Зачем?
От: Wolverrum Ниоткуда  
Дата: 15.01.20 17:58
Оценка:
Здравствуйте, Ватакуси, Вы писали:

В>Предлагайте как это сделать так же ненавязчиво в ц++ и иже с ним. Желательно, чтобы результат совпадал.


Зачем сразу с козырей заходишь? ))
Re[2]: Python в больших проектах
От: Sharov Россия  
Дата: 15.01.20 18:03
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>Мораль: серьезные проекты можно писать только на языках, для которых верно хотя бы одно из двух: 1) у языка есть несколько независимых, влиятельных реализаций 2) за языком стоят люди, которым можно доверять


1)было 2.*, появилось 3.* Две реализации, выбирай не хочу.
2)По идее стоит гугл, ну должен стоять. Гвидо там работал.
Кодом людям нужно помогать!
Re[3]: скала
От: Sharov Россия  
Дата: 15.01.20 18:12
Оценка:
Здравствуйте, Ватакуси, Вы писали:

В> Scala offers very limited community presence.

В> It is not the easily adaptable language.
В> Offers very limited backward compatibility

А что, скала так быстро развивается или сложный язык сам по себе?
Кодом людям нужно помогать!
Re: Python в больших проектах
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 15.01.20 19:22
Оценка:
Здравствуйте, Nuzhny, Вы писали:

N>Новость про Mercurial.

N>Удивительное дело, что такой большой проблемой является переход на новую версию языка, которая появилась уже более 10 лет назад.
N>Спрашивается: нахер оно тогда надо, писать нетленку на динамических языках? Только прототипы! Тут же и тесты не особо помогут, потому что и их надо переписывать. Я раньше как-то не понимал всей глубины проблемы, но сейчас удивляюсь, как вообще можно что-то большое делать на динамике. Плюсовые и шарповые проекты не всегда легко, но достаточно уверенно переползают со стандарта на стандарт, на новые компиляторы и платформы. И 100% покрытия тестами в них нет, но кажется, что само переползание чаще лечит прошлые баги, чем добавляет новых.
N>Вот, просто ужаснулся и захотелось поделиться.

Динамичность и несовместимые изменения ортогональны. Вон в C++ тоже много вещей, которые с 17 или 20 объявлены удалёнными — и что?
Проблема у Питона не в этом, а в том, что в переходе Py2->Py3 не сделали промежуточных ступеней, через которые можно было бы мягко переходить. Теперь в качестве таких ступеней приходится применять модуль six и рантаймовые проверки, которые не ускоряют его.

У меня сейчас как раз основной компонент вышел на работу на Py3, но поддержку Py2 ещё не разрешено удалять. Так что прошёл это всё вживую.

Динамика, да, даёт заметную потерю в скорости написания фич к крупным проектам. Но в Py3 поддержка статического анализа — мы уже наготове её включать
The God is real, unless declared integer.
Re[3]: Python в больших проектах
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 15.01.20 19:26
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>Не очень понятно, почему бы на P2 и не осталься. Ясно же, что это два достаточно разных языка, и P3 никогда не вытеснит P2, они так и будут вечно сосуществовать.


Кому и зачем нужен будет Py2?
The God is real, unless declared integer.
Re[4]: Python в больших проектах
От: Cyberax Марс  
Дата: 15.01.20 19:29
Оценка:
Здравствуйте, Anton Batenev, Вы писали:

S>> 2)По идее стоит гугл, ну должен стоять. Гвидо там работал.

AB>Гвидо покинул питон в 2018, гугл сделал ставку на го, который уже обошел питон по всем фронтам, кроме разве что ML да и то за счет инертности и числа либ.
Для ML нынче требуется REPL в виде Jupyter. Для Go его сделать невозможно из-за того, что он чисто компилируемый.
Sapienti sat!
Re[3]: Давайте сравним
От: Буравчик Россия  
Дата: 15.01.20 19:37
Оценка:
Здравствуйте, alexzzzz, Вы писали:

A>Простая линейная интерполяция с такими же ошибками. Не знаю, что требуется делать, если отсутствуют крайние значения, поэтому проигнорировал.


Код сильно сложнее. Вот поэтому питон более распространен в DS.
Best regards, Буравчик
Re[2]: Python в больших проектах
От: Буравчик Россия  
Дата: 15.01.20 19:39
Оценка:
Здравствуйте, netch80, Вы писали:

N>Динамика, да, даёт заметную потерю в скорости написания фич к крупным проектам. Но в Py3 поддержка статического анализа — мы уже наготове её включать


Уже давно пора. Есть же аннотации+mypy.
Best regards, Буравчик
Re[3]: Python в больших проектах
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 15.01.20 19:44
Оценка:
Здравствуйте, Буравчик, Вы писали:

Б>Здравствуйте, netch80, Вы писали:


N>>Динамика, да, даёт заметную потерю в скорости написания фич к крупным проектам. Но в Py3 поддержка статического анализа — мы уже наготове её включать


Б>Уже давно пора. Есть же аннотации+mypy.


Ну вот будет свисток избавляться от совместимости с Py2 — то как только так сразу. Сейчас же это не пройдёт синтаксически.
The God is real, unless declared integer.
Re[4]: Python в больших проектах
От: Sharov Россия  
Дата: 15.01.20 20:21
Оценка:
Здравствуйте, Anton Batenev, Вы писали:

AB>Гвидо покинул питон в 2018, гугл сделал ставку на го, который уже обошел питон по всем фронтам, кроме разве что ML да и то за счет инертности и числа либ. Лет 5 назад начинать проект на питоне было неплохим выбором, но надо вовремя уметь остановиться и принять, что py2 и py3 это разные языки. Плюс, кажется, последний собирается повторить судьбу Perl6.


Т.е. Вы не советуете в него инвестировать время? Я как раз начал его активно изучать. В связи с ML, конечно.
Perl6 потому что никто не будет использовать? Ну не думаю, в ml нонче столько народу, что ход у него будет неплохой.
Как по мне, но перпективы питона радужнее чем шарпа.
Кодом людям нужно помогать!
Re[4]: Python в больших проектах
От: Masterspline  
Дата: 15.01.20 22:08
Оценка:
AB>Гвидо покинул питон в 2018, гугл сделал ставку на го, который уже обошел питон по всем фронтам, кроме разве что ML да и то за счет инертности и числа либ. Лет 5 назад начинать проект на питоне было неплохим выбором, но надо вовремя уметь остановиться и принять, что py2 и py3 это разные языки. Плюс, кажется, последний собирается повторить судьбу Perl6.

Perl6 тоже переименовали. Теперь он не Perl вовсе.
Re[6]: Python в больших проектах
От: Pzz Россия https://github.com/alexpevzner
Дата: 16.01.20 05:22
Оценка:
Здравствуйте, kaa.python, Вы писали:

KP>Ниши и подход к разработке Python и Go настолько разные, что они даже не особо конкуренты друг другу. Python еще будет жить очень долго, я бы скорее предположил что Go раньше помрет.


У Go совсем другая ниша. Это скорее C 2.0, чем компилируемый питон.
Re[4]: Python в больших проектах
От: Pzz Россия https://github.com/alexpevzner
Дата: 16.01.20 05:29
Оценка:
Здравствуйте, Masterspline, Вы писали:

M>Ну и самый главный вопрос. Зачем сейчас пользоваться ртутью, которая создает кучу сложностей, если есть git, в котором таких сложностей нет? Новички hg не знают, а если заставить разобраться, каждый раз запуская hg человек будет думать "нахрен мне нужен этот инструмент, когда есть git", что со временем перерастет в "нахрен мне нужен этот работодатель". Инфраструктура hg сжимается (битбакет его выкинул на мороз), да и сам меркуриал, написанный на Python2 теперь непонятно как запускать. Зачем бороться с искусственными трудностями, если есть git, который позволяет делать все то же самое, только больше, проще и удобнее.


Потому, что проще сдохнуть, чем привыкнуть к этому вашему git'у. А у hg все команды идут напрямую из CVS, к которому программистов моего поколения еще в детском садике приучили (нам так воспиталка и говорила: "покакал — возьми листочек бумажки, подпиши на нем изменения и закоммитеть не забудь").
Re[4]: Python в больших проектах
От: so5team https://stiffstream.com
Дата: 16.01.20 06:19
Оценка:
Здравствуйте, Masterspline, Вы писали:

M>Ну и самый главный вопрос. Зачем сейчас пользоваться ртутью, которая создает кучу сложностей, если есть git, в котором таких сложностей нет?


Зачем пользоваться VSCode, если есть vim?
Зачем пользоваться vim, если есть emacs?
Зачем пользоваться emacs, если есть...

Люди разные, привычки разные, потребности разные.

Ваш К.О.
Re[2]: Python в больших проектах
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 16.01.20 07:33
Оценка:
Здравствуйте, novitk, Вы писали:

N>Заголовок не соответствует содержанию. Чувак из меркуриала жалуется на переход py2->py3, а не на динамику. Представь себе C++ теряет обратную совместимость и остается без поддержки и всем предлагается перейти на С+++? Сильно тебе статика поможет?


Да, конечно. Компилятор + статический анализатор кода (он по-умолчанию мощнее питоновского) найдут срау же множество проблем. Ты не знал?!!

N>Ключевой система по расчету риска для двух инвест.банка написана на Питоне (>1мм LoC) на который перешли со .... Smalltalk-a.


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

N>Сейчас я работаю с такой же системой в еще одном инвест банке(все три входят в первую пятерку в мире), где вместо Питона решили использовать Скалу. Результат в продуктивности имхо сильно хуже чем с Питоном, хотя это пожалуй самый продвинутый язык в относительном мэйнстриме. Поэтому кванты потихоньку саботируют и пишут на питончике, хотя в IT конечно так сделать наверно не дадут.


В какой продуктивности? Пишется медленнее? Работает медленнее? А как дела с процентом багов в коде?
Re[2]: Python в больших проектах
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 16.01.20 07:36
Оценка:
Здравствуйте, netch80, Вы писали:

N>Динамичность и несовместимые изменения ортогональны. Вон в C++ тоже много вещей, которые с 17 или 20 объявлены удалёнными — и что?


А то, что тебе об этом скажет компилятор. В случае с Питоном ты не узнаешь о проблемах, пока этот код не выполнится. Этого разве мало?
Re[4]: Python в больших проектах
От: Буравчик Россия  
Дата: 16.01.20 07:36
Оценка:
Здравствуйте, Anton Batenev, Вы писали:

AB>Гвидо покинул питон в 2018, гугл сделал ставку на го, который уже обошел питон по всем фронтам, кроме разве что ML да и то за счет инертности и числа либ. Лет 5 назад начинать проект на питоне было неплохим выбором, но надо вовремя уметь остановиться и принять, что py2 и py3 это разные языки.


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

AB>Плюс, кажется, последний собирается повторить судьбу Perl6.


Почему тебе так кажется?
Python приятный язык. Почти все библиотеки поддерживают python 3.
Язык продолжает развиваться, не ломая обратную совместимость. Все в порядке
Best regards, Буравчик
Re[2]: Python в больших проектах
От: Vain Россия google.ru
Дата: 16.01.20 07:46
Оценка:
Здравствуйте, kov_serg, Вы писали:

N>>Новость про Mercurial.

N>>Вот, просто ужаснулся и захотелось поделиться.
_>

_># Mercurial will never work on Python 3 before 3.5 due to a lack
_># of % formatting on bytestrings, and can't work on 3.6.0 or 3.6.1
_># due to a bug in % formatting in bytestrings.
_># We cannot support Python 3.5.0, 3.5.1, 3.5.2 because of bug in
_># codecs.escape_encode() where it raises SystemError on empty bytestring

Это ещё что, у них баги иногда висят неопределённоое количество лет в Win32 имплементации, только недавно вот пофиксили:
https://bugs.python.org/issue37380: `subprocess.Popen._cleanup() "The handle is invalid" error when some old process is gone`
https://bugs.python.org/issue37549: `os.dup() fails for standard streams on Windows 7`

У меня оно время от времени до сих пор выстреливает и типа никто этого не заметил за много много лет.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[6]: Python в больших проектах
От: Sharov Россия  
Дата: 16.01.20 10:08
Оценка:
Здравствуйте, kaa.python, Вы писали:

KP>Ниши и подход к разработке Python и Go настолько разные, что они даже не особо конкуренты друг другу. Python еще будет жить очень долго, я бы скорее предположил что Go раньше помрет.


Вместе с гуглом, наверное.
Кодом людям нужно помогать!
Re[3]: Давайте сравним
От: Mamut Швеция http://dmitriid.com
Дата: 16.01.20 10:11
Оценка:
Б>Не понравилось, что используются циклы, а также сторонние библиотеки. Можно обойтись без них.
Б>
Б>import numpy as np
Б>import pandas as pd
Б>




dmitriid.comGitHubLinkedIn
Re[6]: Python в больших проектах
От: Буравчик Россия  
Дата: 16.01.20 10:20
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Мнэээ. Даже в оригинальном сообщении в статье говорится прямым текстом: было сломано дофига обратной совместимости. Настолько, что под давлением коммьюнити некоторые изменения постепенно откатывали назад. Но настолько медленно, что крупные проекты стало возможно переводить только начная с Питона 2.7 и 3.5, не раньше.


Ок, поясню. Проблема обратной совместимости остро стояла только при переходе с 2 на 3. Сейчас (уже несколько лет!) балом правит версия 3. И она продолжает развиваться без потери обратной совместимости. Изменения в питон 4 не планируют делать "шокирующими", как при переходе на 3. Так что, с языком, как с рабочим инструментом, все в порядке
Best regards, Буравчик
Re[7]: Python в больших проектах
От: Mamut Швеция http://dmitriid.com
Дата: 16.01.20 10:28
Оценка:
Б>Ок, поясню. Проблема обратной совместимости остро стояла только при переходе с 2 на 3.

«Только». Настолько «только», что переход занял 10 лет, и еще не закончился, несмотря на то, что поддержка заканчивается в этом году.

Б>Сейчас (уже несколько лет!) балом правит версия 3.


«Несколько лет правит балом» === «может быть последние года три, наконец-то, на третью версиб перешло больше народа, чем тех, кто не перешел». Очень удивительно, что такой факап питон пережил.


dmitriid.comGitHubLinkedIn
Re[7]: Python в больших проектах
От: Mamut Швеция http://dmitriid.com
Дата: 16.01.20 10:28
Оценка:
KP>>Ниши и подход к разработке Python и Go настолько разные, что они даже не особо конкуренты друг другу. Python еще будет жить очень долго, я бы скорее предположил что Go раньше помрет.

S>Вместе с гуглом, наверное.


А что Гугл? У Гегла есть собственные какие-то проекты, которые гарантируют выживаемость Го?


dmitriid.comGitHubLinkedIn
Re[8]: Python в больших проектах
От: Masterspline  
Дата: 16.01.20 11:04
Оценка:
KP>>>Ниши и подход к разработке Python и Go настолько разные, что они даже не особо конкуренты друг другу. Python еще будет жить очень долго, я бы скорее предположил что Go раньше помрет.

S>>Вместе с гуглом, наверное.


M>А что Гугл? У Гегла есть собственные какие-то проекты, которые гарантируют выживаемость Го?


Странный ты. Гугл придумал GoLang как замену Python. Он же его и развивает (а Python уже нет). У них, конечно, есть проекты на GoLang. Неужели ты этого не знаешь? Или я что-то не так понял?
Re[3]: Давайте сравним
От: Ватакуси Россия  
Дата: 16.01.20 11:08
Оценка:
Б>Не понравилось, что используются циклы, а также сторонние библиотеки. Можно обойтись без них. Поэтому еще вариант на питон:
Можно вообще на голом питоне написать, но становится менее понятно что это. И как это.
Все будет Украина!
Re[3]: Python в больших проектах
От: Ватакуси Россия  
Дата: 16.01.20 11:10
Оценка:
N>>Динамичность и несовместимые изменения ортогональны. Вон в C++ тоже много вещей, которые с 17 или 20 объявлены удалёнными — и что?

N>А то, что тебе об этом скажет компилятор. В случае с Питоном ты не узнаешь о проблемах, пока этот код не выполнится. Этого разве мало?

Подключиал анотации и стат-аналих и вуаля.
Все будет Украина!
Re[9]: GoLang как замену C/C++
От: Mamut Швеция http://dmitriid.com
Дата: 16.01.20 11:18
Оценка:
M>Странный ты. Гугл придумал GoLang как замену Python.

Можно посмотреть, что говорит Rob Pike: https://talks.golang.org/2012/splash.article

Можешь сам посчитать, сколько там описано моментов «Go vs C/C++ и Java» и «Go vs Python»


dmitriid.comGitHubLinkedIn
Re[5]: Python в больших проектах
От: Skorodum Россия  
Дата: 16.01.20 11:24
Оценка:
Здравствуйте, so5team, Вы писали:

S>Зачем пользоваться VSCode, если есть vim?

S>Зачем пользоваться vim, если есть emacs?
S>Зачем пользоваться emacs, если есть...
Не, аналогия не верная: твой редактор не накладывает никаких ограничений на коллег и рабочий процесс, в отлчиии от VCS.
Re[5]: Python в больших проектах
От: Sharov Россия  
Дата: 16.01.20 11:50
Оценка:
Здравствуйте, Cyberax, Вы писали:

AB>>Гвидо покинул питон в 2018, гугл сделал ставку на го, который уже обошел питон по всем фронтам, кроме разве что ML да и то за счет инертности и числа либ.

C>Для ML нынче требуется REPL в виде Jupyter. Для Go его сделать невозможно из-за того, что он чисто компилируемый.

Почему нельзя Го сделать интерпритируемым, из-за горутин? Для шарпа же сделали -- https://devblogs.microsoft.com/dotnet/net-core-with-juypter-notebooks-is-here-preview-1/
Кодом людям нужно помогать!
Re[6]: Python в больших проектах
От: so5team https://stiffstream.com
Дата: 16.01.20 12:26
Оценка:
Здравствуйте, Skorodum, Вы писали:

S>>Зачем пользоваться VSCode, если есть vim?

S>>Зачем пользоваться vim, если есть emacs?
S>>Зачем пользоваться emacs, если есть...
S>Не, аналогия не верная: твой редактор не накладывает никаких ограничений на коллег и рабочий процесс,

Вообще-то накладывает. Начиная от tabs vs spaces, и заканчивая наличием готовых шаблонов для проектов, работающих в фоне анализаторов/линтеров и пр.

S>в отлчиии от VCS.


Есть принципиальные отличия Centralized VCS (CVS, Svn) от Decentralized VCS (git, hg). Между git и hg для большинства разработчиков различий не так уж и много. Тут скорее все упирается в то, что уже развернуто в компании для целей CI/CD и code review. Если уже все настроено на Hg, то надобность в уникальных возможностях git будут испытывать только отдельные особо продвинутые товарищи. Ровно как и в обратном случае с git.
Re[4]: Давайте сравним
От: Буравчик Россия  
Дата: 16.01.20 12:29
Оценка:
Здравствуйте, Ватакуси, Вы писали:

Б>>Не понравилось, что используются циклы, а также сторонние библиотеки. Можно обойтись без них. Поэтому еще вариант на питон:

В>Можно вообще на голом питоне написать, но становится менее понятно что это. И как это.

Просто небольшой рефакторинг. По сути — претензий нет, дело вкуса.
Best regards, Буравчик
Re[6]: Python в больших проектах
От: Pzz Россия https://github.com/alexpevzner
Дата: 16.01.20 12:48
Оценка:
Здравствуйте, Masterspline, Вы писали:

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


Потому, что этот ваш гит чертовски нелогичен. Вот объясни мне, мил человек, за каким чертом в нем бывают локальные метки, которые ни в какой репозиторий не попадут, и нелокальные? И почему push по умолчанию не уносит метки с собой, а требует отдельной опции для этого?

M>В последнее время считаю, что если кто-то пользуется маргинальщиной — это от чрезмерной упертости и с такими лучше не связываться (разве что это будет хорошо компенсироваться). Новость про hg это только подтверждает. Но, из любого правила бывают исключения, поэтому, в каждом конкретном случае нужно разбираться.


А ты и не заметишь, работая со мной, что я меркурем пользуюсь. Я с твоим гитом через hg-git буду работать.

M>P.S. CVS я тоже застал (Opera3.5b сменила netscape 3 gold, mingw только появился на Win95 i486 с 8М памяти).


А период, когда все, высунув язык, стали с CVS на SVN переползать, застал? А сам на SVN переполз?
Re[5]: Давайте сравним
От: Ватакуси Россия  
Дата: 16.01.20 13:20
Оценка:
Б>>>Не понравилось, что используются циклы, а также сторонние библиотеки. Можно обойтись без них. Поэтому еще вариант на питон:
В>>Можно вообще на голом питоне написать, но становится менее понятно что это. И как это.

Б>Просто небольшой рефакторинг. По сути — претензий нет, дело вкуса.

Кстати, зачем reset_index тут?
Все будет Украина!
Re[6]: Давайте сравним
От: Буравчик Россия  
Дата: 16.01.20 13:30
Оценка:
Здравствуйте, Ватакуси, Вы писали:

В>Кстати, зачем reset_index тут?


Да, в данном случае reset_index не обязателен (если по missings_indexes вытаскиваем данные из np.ndarray). Забыл исправить.

Изначально моя функция возвращала весь датафрейм: df[missings_indexes].
Но т.к. индексы были изменены в set_index(date) пришлось добавить reset_index().
Потом увидел, что ты возращаешь ndarray, переделал, а reset_index не убрал.
Best regards, Буравчик
Re[7]: Давайте сравним
От: Ватакуси Россия  
Дата: 16.01.20 13:55
Оценка:
В>>Кстати, зачем reset_index тут?

Б>Да, в данном случае reset_index не обязателен (если по missings_indexes вытаскиваем данные из np.ndarray). Забыл исправить.


Б>Изначально моя функция возвращала весь датафрейм: df[missings_indexes].

Б>Но т.к. индексы были изменены в set_index(date) пришлось добавить reset_index().
Б>Потом увидел, что ты возращаешь ndarray, переделал, а reset_index не убрал.

Понятно.
Кстати, to_datetime справится с произвольной датой (и форматом) как parser.parse? Мне казалось, что он более капризный
Все будет Украина!
Re[8]: Давайте сравним
От: Буравчик Россия  
Дата: 16.01.20 15:06
Оценка:
Здравствуйте, Ватакуси, Вы писали:

В>Кстати, to_datetime справится с произвольной датой (и форматом) как parser.parse? Мне казалось, что он более капризный


Думаю, что более капризный, но не уверен. Тоже хочу знать.
У to_datetime под капотом, наверное, тот же код, что и в TimeStamp. А вот какие он умеет парсить даты/время я не знаю.
Best regards, Буравчик
Re[11]: Python в больших проектах
От: Sharov Россия  
Дата: 16.01.20 15:27
Оценка:
Здравствуйте, Nuzhny, Вы писали:

N>
  Картинка
N>Image: slack-imgs.com.jpeg

brilliant это что, хацкель или Си? И почему не способны? Кмк, гуглеры крутые, что не могут осилить какую-нибудь функциональщину или Си?
Кодом людям нужно помогать!
Re[4]: Python в больших проектах
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 17.01.20 06:56
Оценка:
Здравствуйте, novitk, Вы писали:

N>>>Заголовок не соответствует содержанию. Чувак из меркуриала жалуется на переход py2->py3, а не на динамику. Представь себе C++ теряет обратную совместимость и остается без поддержки и всем предлагается перейти на С+++? Сильно тебе статика поможет?

N>>Да, конечно. Компилятор + статический анализатор кода (он по-умолчанию мощнее питоновского) найдут срау же множество проблем. Ты не знал?!!
N>Статический анализатор кода даст тебе некоторые, весьма слабые в случае Java, гарантии, но код на другом языке писать не будет.

Не, не, не, ты сам начал говорить про С++. Так в этом мире уже случился плавный переход к С+++ от 2003 до С++17 (в этом году будет ещё больше — модули). Тут разница намного больше, чем с Питонами, но переход, по сути, безболезненный. Да, что-то по-мелочи появлялось, что-то становилось deprecated, но проекты просто плавно переползали с версии на версию, зачастую собираясь разными версиями компиляторов. Как раз и начался расцвет статических анализаторов для С++ в это время, не только PVS, которую рекламирую на RSDN.

N>Системы написанные на Яве проиграли в конкурентной борьбе.


Прямо таки везде? Или только у вас?

N>>К тому же, была бы возможность использовать разные языки (ту же Scala) для разных задач в рамках одной платформы.

N>Ты так говоришь, как будто зоопарк это нечто хорошее.

Как будто зоопарк Scala + Питон (это тоже по твоим словам) лучше, чем Java + Scala.

N>>В какой продуктивности? Пишется медленнее? Работает медленнее? А как дела с процентом багов в коде?

N>Пишется медленее. Ты преувеличиваешь способность статического анализа по снижению процента багов. Большинство ошибок, которые выявляет широко используемые статические языки, до продакшена у питона тоже не доходят.

Ну так себе утверждение, чтобы в него поверить без аргументов.
Re[5]: Python в больших проектах
От: novitk США  
Дата: 17.01.20 14:18
Оценка:
Здравствуйте, Nuzhny, Вы писали:

N>Не, не, не, ты сам начал говорить про С++.

Я начал говорить про C+++(три плюса!) — вымышленный, похожий, но не совместимый с C++ язык для аналогии с py2->py3.

N>Так в этом мире уже случился плавный переход к С+++ от 2003 до С++17 (в этом году будет ещё больше — модули). Тут разница намного больше, чем с Питонами, но переход, по сути, безболезненный.

Ключевое слово "плавный". У питона он был резким, но это не про статику с динамикой. Тот же JS обрастал фучами и менялся без потери совместимости.

N>>Системы написанные на Яве проиграли в конкурентной борьбе.

N>Прямо таки везде? Или только у вас?
Про везде не знаю, но на Wall Street так. Насколько я знаю в долине тоже.

N>Как будто зоопарк Scala + Питон (это тоже по твоим словам) лучше, чем Java + Scala.

Правильно. Поэтому лучше только Питон. Ну и плюсы для скорости, куда же без них. Зоопарк возник от того, что "два часа" в питоне превращаются в "две недели" в скале. Возможно это из за недоработок у нас в реализации компилятора/workflow/CI. Я вообще за статику и изначально казалось, что Scala достаточна близка по удобству, но императивно выяснилось, что увы нет.
Re[7]: Python в больших проектах
От: Skorodum Россия  
Дата: 17.01.20 14:39
Оценка:
Здравствуйте, so5team, Вы писали:

S>Вообще-то накладывает.

Вообще-то нет.

S>Начиная от tabs vs spaces

Абсолютно ортогонально редакторам (обычно редакторы одинаково хорошо поддерживают оба варианта).

S>и заканчивая наличием готовых шаблонов для проектов

Какие еще шаблоны для редакторов?

S>работающих в фоне анализаторов/линтеров и пр.

Все это абсолютно не принципиально. Ну вот крутится у меня clang-backend в QtCreator и дает подсказки по С++, моим коллегам со студией, VIM или VisualCode это фиолетово.
У нас в компании для одного и того же когда используются почти все популярные IDE: CLion, QtCreator, Vim, MSVC, VisualCode. И это не считаю специализированных embedded IDE: IAR/SEGGER/Atmel.
А вот VCS — одна.

S>Есть принципиальные отличия Centralized VCS (CVS, Svn) от Decentralized VCS (git, hg). Между git и hg для большинства разработчиков различий не так уж и много.

Во-во, а выше вы же пишите:

Люди разные, привычки разные, потребности разные.

hg и git закрывают абсолютно одни и теже потребности, только git на пару порядков популярнее (ну так сложилось). Поэтому hg — сейчас "странная (редкая) привычка".
Re[8]: Python в больших проектах
От: so5team https://stiffstream.com
Дата: 17.01.20 15:36
Оценка:
Здравствуйте, Skorodum, Вы писали:

S>hg и git закрывают абсолютно одни и теже потребности, только git на пару порядков популярнее (ну так сложилось). Поэтому hg — сейчас "странная (редкая) привычка".


IDEA и VisualStudio сильно популярнее vim-а и emacs-а. Что не мешает отдельным людям быть продуктивнее именно с vim/emacs.

Собственно, почему бы отдельным разработчикам не быть продуктивнее именно с hg, а не с git-ом.
Re: Python в больших проектах
От: dsorokin Россия  
Дата: 17.01.20 18:09
Оценка:
Здравствуйте, Nuzhny, Вы писали:

N>Спрашивается: нахер оно тогда надо, писать нетленку на динамических языках?


(все нижеследующее на правах авторского троллинга)

Из всех динамических языков более-менее для этого годится лишь ветхий и обросший мхом Common Lisp (CL) на мой взгляд. Он является Lisp-N, а поэтому в нем проверок во время компиляции заметно больше, чем в других динамических языках. К примеру, опечататься в названии функции в CL намного сложнее, тогда как в тех же схемке или питончике — как нефиг делать.

Ну, а применение отличных от CL динамических языков для больших проектов лично у меня ассоциируется с "троллейбусом из буханки": возможно, но не всегда разумно
Re[5]: Python в больших проектах
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 18.01.20 07:56
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>Потому, что проще сдохнуть, чем привыкнуть к этому вашему git'у. А у hg все команды идут напрямую из CVS,


И в третий раз повторю только на этом форуме: мне после CVS было легче перейти на Git, чем SVN, Hg или ещё какой-то временно модный ужас.
"Напрямую из CVS" для Hg это миф. Зачем, например, у Hg раздельные pull и update? В CVS такого не было.
The God is real, unless declared integer.
Re[4]: Python в больших проектах
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 18.01.20 08:00
Оценка:
Здравствуйте, Erop, Вы писали:

E>>>В целом мне лично не понятно, зачем вообще переписывать что-то большое с P2 на P3, а не на какой-нибудь более типизированный язык...


N>>Затем, что для обычного проекта такой переход на Py3 раз в 10-100 дешевле переписки на совсем другой язык.

E>А вообще не переписывать -- ещё дешевле... Зачем вообще P2 менять на P3?

Ну если у тебя ну очень низкосистемные задачи — можешь не переписывать. Я в этом смысле приветствовал, например, сохранение Perl4 во FreeBSD — была простая понятная вещь, как раз для двухстраничного клея. Но его перестали развивать и лечить...

А если что-то прикладное, то, например, кошмар путаний между str и unicode в Py2 уже заслуживал нормализации.

E> Это, примерно, как переписать что-то с С++ на D, только ещё более бессмысленно...


Абсолютно некорректная аналогия.
The God is real, unless declared integer.
Re[3]: Python в больших проектах
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 18.01.20 08:14
Оценка:
Здравствуйте, Nuzhny, Вы писали:

N>>Динамичность и несовместимые изменения ортогональны. Вон в C++ тоже много вещей, которые с 17 или 20 объявлены удалёнными — и что?


N>А то, что тебе об этом скажет компилятор. В случае с Питоном ты не узнаешь о проблемах, пока этот код не выполнится. Этого разве мало?


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

Но всё равно это не про то, это не про динамику как таковую, это уже про метапрограммирование. Аналог варианта C++ это если, например, метод просто исчез из класса. Такие вещи для Питона находятся статическими анализаторами (если ты не читерствуешь с какой-то хитрой подстановкой, генерацией класса в рантайме и т.п.); опять же, я стараюсь по максимуму обходиться без такого. Да, есть любители всё построить на метаклассах, на генераторах классов и т.п. Но мы в своих проектах пишем так, чтобы, грубо говоря, можно было перенести на какую-нибудь Java 1:1 хоть завтра без напряга мозга, только чуть уточнить самый системный уровень.

Итого, тут я скорее принимаю аргумент, но в том, что в Питоне ты не обязан писать так, чтобы статический анализ не сработал, но слишком легко сделать так, и есть много любителей так делать. Можно их бить для улучшения мировой кармы
The God is real, unless declared integer.
Re[6]: Python в больших проектах
От: Pzz Россия https://github.com/alexpevzner
Дата: 18.01.20 10:10
Оценка:
Здравствуйте, netch80, Вы писали:

N>И в третий раз повторю только на этом форуме: мне после CVS было легче перейти на Git, чем SVN, Hg или ещё какой-то временно модный ужас.


Почему?

N>"Напрямую из CVS" для Hg это миф. Зачем, например, у Hg раздельные pull и update? В CVS такого не было.


Наверное, для симметрии. Раздельные commit и push понятно почему, вот и сделали раздельные pull и update.

А зачем в гите измененные файлы надо add перед commit? Он же и так видит, какие файлы изменились. И почему ходовая команда "покажи diff между моей рабочей версией и последней версией из репозирория" такая длинная.

А еще, зачем push для меток и push вообще — это разные команды? Как вообще там это сделано? Там что, для меток отдельный blokchain ведется?
Re[5]: Python в больших проектах
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 18.01.20 13:47
Оценка:
Здравствуйте, Mamut, Вы писали:


M>Это должно было показать, что нет никакой разницы между питоном и C++, что ли?


M>C++: создать сборочный файл, запустить компиляцию, запустить файл

M>Python: python файл_в_котором_кот.py

M>


Ну да, хеловорды делать проще на питоне
Маньяк Робокряк колесит по городу
Re[5]: Python в больших проектах
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 18.01.20 13:59
Оценка:
Здравствуйте, Pzz, Вы писали:

V>>Например, вот так:

V>>
V>>LIBS += -lcryptopp
V>>


Pzz>Это все хорошо, когда нужная тебе библиотека есть в виде стандартного пакета для твоего дистрибутива твоей любимой ОС. А когда нету, начинается беда.


А для питона как?
Маньяк Робокряк колесит по городу
Re[3]: Python в больших проектах
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 18.01.20 14:01
Оценка:
Здравствуйте, Pzz, Вы писали:

E>>Просто P2 и P3 шибко разные. Первый про списки, а второй про итераторы, например.

E>>В целом мне лично не понятно, зачем вообще переписывать что-то большое с P2 на P3, а не на какой-нибудь более типизированный язык...

Pzz>Не очень понятно, почему бы на P2 и не осталься. Ясно же, что это два достаточно разных языка, и P3 никогда не вытеснит P2, они так и будут вечно сосуществовать.


Я когда-то пописывал на 2.7, а тут попробовал 3.6.
Если честно, кроме мелких отличий синтаксиса никакой особой разницы и не заметил.
Но я так, видимо, нуб, не проникнувшийся ни идеологией П2, ни идеологией П3
Маньяк Робокряк колесит по городу
Re[2]: Python в больших проектах
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 18.01.20 14:06
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>Дело не в динамике, а в том, что кое-кто, не подумав, вносит ломающие изменения в язык.


Pzz>Мораль: серьезные проекты можно писать только на языках, для которых верно хотя бы одно из двух: 1) у языка есть несколько независимых, влиятельных реализаций 2) за языком стоят люди, которым можно доверять


Только я бы уточнил: вот доверяешь ты такой людям, доверяешь — а потом раз — и трамвай переехал. Ну, или просто задолбало их пилить дальше
Маньяк Робокряк колесит по городу
Re[6]: Python в больших проектах
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 18.01.20 14:26
Оценка:
Здравствуйте, novitk, Вы писали:

N>>Не, не, не, ты сам начал говорить про С++.

N>Я начал говорить про C+++(три плюса!) — вымышленный, похожий, но не совместимый с C++ язык для аналогии с py2->py3.

Для статически типизируемого языка гораздо проще написать конвертер. Те же PVS, уверен, с радостью бы взялись, если бы такая необходимость появилась бы
Маньяк Робокряк колесит по городу
Re[6]: Python в больших проектах
От: Pzz Россия https://github.com/alexpevzner
Дата: 18.01.20 14:37
Оценка:
Здравствуйте, Marty, Вы писали:

Pzz>>Это все хорошо, когда нужная тебе библиотека есть в виде стандартного пакета для твоего дистрибутива твоей любимой ОС. А когда нету, начинается беда.


M>А для питона как?


Не знаю.

Для Go очень хорошо: делаешь import, указав прям путь к гитхабовскому репозиторию
Re[9]: Python в больших проектах
От: Skorodum Россия  
Дата: 20.01.20 09:14
Оценка:
Здравствуйте, so5team, Вы писали:

S>IDEA и VisualStudio сильно популярнее vim-а и emacs-а. Что не мешает отдельным людям быть продуктивнее именно с vim/emacs.

S>Собственно, почему бы отдельным разработчикам не быть продуктивнее именно с hg, а не с git-ом.
С такой формулировкой я абсолютно согласен Вопрос-то в том, что другие сотудники будут в среднем менее продуктивны или их сложнее будет найти.
В частном случае что угодно может быть эффективнее, но в общем случае и в долгосрочной перспективе и для сотрудников и для компаний git однозначно предпочтительней.
Re[8]: Python в больших проектах
От: Pzz Россия https://github.com/alexpevzner
Дата: 20.01.20 11:17
Оценка:
Здравствуйте, 13akaEagle, Вы писали:

Pzz>>Не знаю.

Pzz>>Для Go очень хорошо: делаешь import, указав прям путь к гитхабовскому репозиторию

E>pip install git+https://github.com/...


pip install гадит в какую-то свою кучу, общую для всех, а Go управляет зависимостями для каждого проекта отдельно и независимо от прочих проектов.
Re[3]: Давайте сравним
От: anonymous Россия http://denis.ibaev.name/
Дата: 20.01.20 21:08
Оценка:
Здравствуйте, Буравчик, Вы писали:

Б> lines = list(islice(sys.stdin, count))


Память больше не ресурс? А если файл размером в терабайт?
Re[4]: Давайте сравним
От: Буравчик Россия  
Дата: 20.01.20 21:58
Оценка:
Здравствуйте, anonymous, Вы писали:

A>Здравствуйте, Буравчик, Вы писали:


Б>> lines = list(islice(sys.stdin, count))


A>Память больше не ресурс? А если файл размером в терабайт?


Тогда весь код надо переписывать, а не только эту строку.
Best regards, Буравчик
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.