Здравствуйте, 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.

Здравствуйте, 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

Нужен. Мне нужен.

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

N>>>Я пару раз попадал на это
В>>На ц++ хелл? Или откатывание пипа?

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

Хорошую вещь пипом не назовут

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

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

V>LIBS += -lcryptopp
V>

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

Здравствуйте, kaa.python, Вы писали:

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

А ему библиотеки подключать очень легко дается. Вот, время и освобождается

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

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

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

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

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

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

Здравствуйте, 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) и тому подобное. При компиляции должен получаться максимально быстрый и компактный код. Но в результате имеем божественные объекты, в коде понапиханы макросы, не функциональный код (АОП) мешает анализировать алгоритм, ещё и чужие библиотеки, которые переписывают как вздумается.

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

Кто виноват и что делать? Виноват ли язык программирования, а может это программисты так пишут и потом распространяют.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Завязывать новый проект не стоит. Но на 2-м питоне уже написано некоторое количество ценных проектов — тот же меркурий.

Pzz>Завязывать новый проект не стоит. Но на 2-м питоне уже написано некоторое количество ценных проектов — тот же меркурий.

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

N>>>Я пару раз попадал на это
В>>На ц++ хелл? Или откатывание пипа?

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

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

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

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

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

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

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

Scala offers very limited community presence.
It is not the easily adaptable language.
Offers very limited backward compatibility

"Плохой питон" печатает отсутствующие данные из поступающего через 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

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

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

Зачем сразу с козырей заходишь? ))