Разработчики Qt представили (http://blog.qt.io/blog/2018/04/13/qt-for-python-is-coming-to.../) проект Qt for Python (https://wiki.qt.io/Qt_for_Python), в рамках которого будет сосредоточено развитие набора для создания графических приложений на языке Python с использованием Qt5. Модуль PySide2 (http://pyside.org) сохранит своё прежнее имя, Qt for Python лишь проект для разработки PySide2 и других возможностей, связанных с поддержкой языка Python.
URL: http://blog.qt.io/blog/2018/04/13/qt-for-python-is-coming-to.../
Новость: https://www.opennet.me/opennews/art.shtml?num=48437
>переводится в разряд первичных языков разработки для QtНе C++ и хорошо
> Не C++ и хорошоСовременный C++ - отличный язык, особенно с удобствами Qt, особенно если не писать на нем интерфейс, а только логику.
Логику писать на низкоуровневом языке, где логика... ;)
Там, где ты ее напишешь
Отбросьте уже эти мифы о C++ о низкоуровневости и якобы сложности. Тем более в паре с Qt.
Сложность С++ - не миф, а медицинский факт. Never trust a programmer who says he knows C++.
C++-это язык общего назначения, а не низкоуиовневый язык. Не путайте с C.
Ну на Питоне писать логику - это посвятить жизнь отладке. Там же 4-е if'а в худшем случае дают 16 путей выполнения, а язык-то интерпретируемый, статические анализаторы работают, мягко говоря, неидеально.В общем, там, где один запуск программы полностью её тестирует - в Mashine Learning или околонаучных вычислениях, это допустимо (хотя полная компиляция за малое время тоже бы не помешала). А вот в GUI это должно привести к некоторому ахтунгу.
Бред пишут те, кто ничего толкового на нем не написал, тем более GUI.
Нет, пока в него не завезут GC из коробки. 99% GUI софта таково что ручное управление памятью там даром не нужно.
Откройте для себя контроль QObject из Qt и умные указатели из C++11.
Кроме того, Qt - не только C++, но ещё и QML для GUI.
Уже 7 лет в C++ GC из коробки.
> Уже 7 лет в C++ GC из коробки.Пруф?
Умные указатели, не не слышал...
Сколько там сейчас томов руководство по С++ ?
Пайк расскзаал, что забыл их при перезде и теперь пилит Go,
а C++ теперь развивают оставшиеся в прошлом неудачники.
Объектно-ориентированный язык без классов-обёрток для примитивных типов и иерархии классов с корнем в Object.
Он в этом плане даже хуже PHP - хочешь запихнуть в вектор данные разных типов - сначала придумай для них иерархию наследования, иначе апкастинг не пройдёт. Хочешь включить в программу классы написанные другим программистом - придумай иерархию и для них, или методы с преобразованием типов напиши, потому что весь пласт кода на C++ - это одинокие, никак не связанные между собой, островки.
И, конечно же, объединить такой высокий уровень абстракции, как ООП, с ручным управленим памятью - та ещё идейка.
Я вот, честно, не могу придумать ситуации где оправдано использование C++. Хочешь кросс-платформенный ассемблер - возьми C. Хочешь кода, понятного даже ребёнку, как мечтал Алан Кэй, возьми Smalltalk или Python. Любишь шаблоны шаблонов на шаблонах - возми, наконец, Haskell и не мучайся.
>хочешь запихнуть в вектор данные разных типовНакой? Если вам такое требуется, у меня для вас плохие новости.
>Хочешь включить в программу классы написанные другим программистом - придумай иерархию и для них
Зачем?
>или методы с преобразованием типов напиши
Зачем преобразовывать левый класс некого дяди Васи в класс некого дяди Пети? А если вдруг надо, то и на PHP, и на Python этого не сделаешь.
>Я вот, честно, не могу придумать ситуации где оправдано использование C++
Там, где Python будет загибаться, когда разбор скрипта будет накладывать тонны оверхеда.
Всё правильно, плюсую. Потому что С++ - это по сути Си с примотанными скотчем классами и прочими костылями с перекрывающимся функционалом.
Есть же pyqt. Отличается только разработчиком?
> Есть же pyqt. Отличается только разработчиком?Левая поделка vs официальное с официальной поддержкой Qt
Кто лучше?
Тот, кто лучше сделает, очевидно же
Даже если официальное будет в чем-то уступать, оно всё равно будет лучше)
Кроме того, у PySide лицензия LGPL, а не GPL как у PyQt
Оно не будет всё равно лучше, если оно будет медленнее и прожорливее
Дружище, что вы назвали "левой поделкой"?Проект PyQt развивается почти 20 лет, начиная ещё с Qt1 ( https://dot.kde.org/2006/08/09/phil-thompson-talks-about-pyqt ).
IMHO это PySide выглядит "левой поделкой" на фоне PyQt.
PyQt — GPL или коммерческая лицензия, PySide — LGPL.
шиндовс - еула, линукс - ядро. Примерно так.
> шиндовс - еула, линукс - ядро. Примерно так.И к чему это было? Я ответил на вопрос о различиях.
Уже лет 10 это неправда.> The Qt Company supports the free software concept by providing the Qt Open Source Edition, which is licensed under the GNU Lesser General Public License (LGPL) version 3.
> Уже лет 10 это неправда.
>> The Qt Company supports the free software concept by providing the Qt Open Source Edition, which is licensed under the GNU Lesser General Public License (LGPL) version 3.
> http://doc.qt.io/qt-5/opensourcelicense.htmlЧто — неправда? Прочитайте внимательно, о чем речь. Про собственно Qt речь не было.
В pyqt для коммерческого софта нужно денег бошлять по 500$ в год. По этому в свое время и начали делать pyside
https://www.riverbankcomputing.com/commercial/buy -$550+НДС на разработчика.
Про "в год" вроде нигде не написано."Откуда дровишки?"
Очередной студент за зачет сделал обвязку на питоне?.....
А слабо то же самое запилить?
А смысл что-либо делать на питоне? Кому реально он нужен?Только не надо про bigdata, которая на Java/Scala/Clojure, про ML, который на R, Matlab, Julia, администрирование, которое на Ruby и пр. области, не имеющие к питону отношения
Питон нужен всем, кто хочет просто решать свои задачи не заморачиваясь сложным синтаксисом и изобретением велосипедов.
Фраза "не заморачиваться сложным синтаксисом" применима к питону лишь для простейших действий. Там где всё одинаково, хоть на bash, хоть на JS. В чуть более сложных случаях лучше взять язык с регулярным синтаксисом без многочисленных нашлёпок и исключений.
> Фраза "не заморачиваться сложным синтаксисом" применима к питону лишь для простейших действий.
> Там где всё одинаково, хоть на bash, хоть на JS. В
> чуть более сложных случаях лучше взять язык с регулярным синтаксисом без
> многочисленных нашлёпок и исключений.Там все по-разному. Причем, какая-то задача проще на баш решается, а какая-то на питоне. Про js не знаю. На питоне проще думать об алгоритме при обработке каких-то данных т к из синтаксиса 5 слов примерно нужны, а в "баше" все это время займет изучение синтаксиса awk =)
> На питоне проще думать об алгоритме при обработке каких-то данныхОб алгоритме проще думать на родном естесственном языке. Я сам из мира си-подобных языков (C, Java, иной раз JavaScript). Так вот, если получается так, что я вынужден использовать гвидон, 95% времени я провожу за документацией по нему, чтобы выяснить, какой же там еще нескучный синтаксис (!) выдумал гвидо для моих абсолютно примитивнейших задач. Даже на баш я затрачиваю меньше времени, хотя баш - тот еще хитропереподвывернутый язык.
Проще думать на том языке который ты понимаешь. И питон здорово экономит время и нервы за счёт того что 1 строчка примитивнейшего питона в других языках может превратиться в 100 строк нескучного кода.
Благородный дон, конечно же, не приведёт примеров?
Благороодный дон конечно же не в курсе, сколько научных и иных библиотек написано к Питону (и за какой короткий срок) ? Это все относим к примерам ненужности ?
Очередной упoротый питонист, ну расскажи нам сколько, а сколько на других
> Благороодный дон конечно же не в курсе, сколько научных и иных библиотек
> написано к Питону (и за какой короткий срок) ? Это все
> относим к примерам ненужности ?Конечно. Потому что несоизмеримое с питоном количество научных библиотек написано на более пригодных для этого языках типа R, Matlab, Julia. Аргумент "я же ничего кроме питона не знаю" здесь плохой аргумент. Обычно подобные "написанные" библиотеки просто никто потом не использует. Лежат мертвым грузом как иллюстрация к очередной статье.
О, Matlab уже стал свободным?
R и Julia всегда были и будут свободными. Кроме того, R используется в коммерческих СУБД как язык для аналитикиВ отношении Matlab, он просто популярен за пределами РФ
> Благороодный дон конечно же не в курсе, сколько научных и иных библиотек
> написано к Питону (и за какой короткий срок) ? Это все
> относим к примерам ненужности ?Корректно этот же вопрос -- сколько *оригинальных* научных и иных библиотек, т.е. не обёрток, написаны на питоне?
И ещё -- "научных библиотек" -- лукавое выражение. Лучше вот так -- сколько реализаций BLAS на питоне? Сколько пакетов визуализации, способностями хотя бы как гнуплот?
Зачем тебе оригинальные? Полагаешь, что так будет лучше, когда оно написано на интерпретируемом языке или прибито к одной среде? Сила питона как раз в том что куча приличных серьёзных либ в него интегрируется и используется с минимумом затрат. Независимо от задачи ты можешь взять его и быть уверен в нормальном результате.И кстати покажи мне альтернативу Keras на фортране и ко (как это будет выглядеть вообще?).
> Зачем тебе оригинальные? Полагаешь, что так будет лучше, когда оно написано на
> интерпретируемом языке или прибито к одной среде? Сила питона как раз
> в том что куча приличных серьёзных либ в него интегрируется и
> используется с минимумом затрат. Независимо от задачи ты можешь взять его
> и быть уверен в нормальном результате.Таким образом, чтобы этой силе питона быть, должны сначала быть те, кого он обернёт. И на что мне тогда питон? И я совершенно не вижу, как мне это помогает.
Разве если ради (ложного) удовольствия "прям всё на питоне".
Скажем, библиотечная обработка больших матриц куда осмысленнее (и дешевле по затратам выч. ресурса) интегрируется в вычисляющие пакеты класса Октавы или Максимы.> И кстати покажи мне альтернативу Keras на фортране и ко (как это
> будет выглядеть вообще?).Очередная нейронная сеть, что ли? (смотрим, смотрим) Ах, простите, очередная обёртка.
Кстати, я сам писал обёртки, правда, не в питон и не для НС, так что проблемы такого класса ПО мне известны.
Сила питона в том, что оно уже есть.Не понятно, опять же, почему, как выше было написано, программист на си пытается доказать, что питон не нужен. Тебе не нужен - не используй, делов то.
А всякие рейтинги показывают, что питон людям нужен.
Он настолько прост, что стал современной заменой бейсика и паскаля при обучении программированию.
>> Сила питона в том, что оно уже есть.Которая превращается в его слабость при очередном обновлении версии языка.....
>> А всякие рейтинги показывают, что питон людям нужен.
Ни один из опубликованных рейтингов не показывает нужность. Они лишь показывают частоту поиска и объем студенческого кода в репозиториях.
>> Он настолько прост, что стал современной заменой бейсика и паскаля при обучении программированию.
Да не прост он. Это лишь видимость. Он насквозь состоит из нерегулярностей синтаксиста и нашлёпок. Сравните с Ruby, например, где действительно всё просто, хотя и несколько непривычно.
Как учебный язык (не первый), он сгодится. Но как учебный, должен таковым и остаться. Чтобы никому и в голову не приходило тащить его в реальные проекты.
> Сила питона в том, что оно уже есть.А разговор выше был о научных библиотеках.
Кстати, если кто не понял, любая обёртка почти всегда работает хуже оборачиваемого.> Не понятно, опять же, почему, как выше было написано, программист на си
> пытается доказать, что питон не нужен. Тебе не нужен - не
> используй, делов то.Не нужно вульгаризовать мнение других людей. Я уже сказал, что писал макросы для ООО на питоне и ещё другие (мелкие) вещи на питоне, и, скажем, для тех же макросов ООО питон выглядит решением получше, чем ООО-бэйсик и ява. То есть в самом по себе питоне ничего особенного я не вижу.
Но -- питон вовсе не прост, и этого не изменит никакое количество повторений "он настолько прост".
Питон прост лишь постольку, поскольку его загонять в голову первым.
Если раньше изучены си-подобные языки, питон сложен, в том числе из-за неотъемлемой объектности. Говорить о приемлемости питона в качестве средства обучения (начального) программированию можно лишь закрыв глаза на ряд серьёзных проблем.Но я могу понять то, что человек, который всё это питоновское хитромудрие освоил, уже ничего другого учить не захочет (даже не сможет, он уже истратил все резервы).
> Он настолько прост, что стал современной заменой бейсика и паскаля при обучении
> программированию.Во-первых, не "стал", а "используется как". Во-вторых, "кое-где". Если посмотреть на практику западных инженерных колледжей, так там зачастую первый (и иногда единственный) язык это матлаб. Ну и?
Слова не мальчика, но мужа.
>прост лишь постольку, поскольку его загонять в голову первым
>изучены си-подобные языки, питон сложен, в том числе из-за неотъемлемой объектности
>ничего другого учить не захочет (даже не сможет, он уже истратил все резервы)ну это уж совсем глупость - как раз благодаря питону и заходят все эти додиез с рабями и джавами с плюсами без каких либо излишних трудностей. Изучать программирование без жёсткой привязки к объектности и реальной жизни = пустая трата времени.
Вот вижу слова про сложность синтаксиса и логики или что-то такое, что можно проще - когда начнёшь реализовывать _ровно то же самое_ на си, приходи. Посмотрим, какие у тебя унылые простыни кода получаться будут. Да, зачастую всего уже имеющегося (в любом нормальном языке) не нужно для решения _данной_ задачи, но в другой раз ты потратишь кучу времени на отладку и "велосипедостроение" (в очередной раз) из-за того, что о твоём удобстве не позаботились другие. А это всё время и ресурсы.
Однако это всё из разряда "придираться к пробелам". Обычный язык с обычным синтаксисом и кучей всего за кадром, чего не видно на первый взгляд. Питон это не луа какая-нибудь, наверное для твоих задач она ближе и понятней.
>практику западных инженерных колледжей
то-то там на питон все так фапают (и я имею в виду преподавательский состав, а не студентов). Не путайте инженерные задачи с информатикой.
>обёртка почти всегда работает хуже оборачиваемого
я даже не защищаю питон, однако слышать его критику от человека, по-видимому, совершенно не разбирающегося в вопросе, достаточно странно. Не то чтобы таким можно было что-либо доказать в принципе. Можно согласиться с тем, библиотеки, интегрируемые в питон, порой обладают меньшей гибкостью (по сравнению с тем же плюсовым апи), но зачастую это без проблем решается тем, что принято называть "monkey patching". Т.е. возможность получить требуемое поведение (если оно необходимо) имеется даже тут. Но смысл то как раз в том, что все доступные фичи оборачиваются в приятный и удобоваримый формат, пригодный для использования.
> ну это уж совсем глупость - как раз благодаря питону и заходят
> все эти додиез с рабями и джавами с плюсами без каких
> либо излишних трудностей. Изучать программирование без жёсткой привязки к объектности
> и реальной жизни = пустая трата времени.Открытие века. Даже два.
Старина, ты себе люби питон или трубочки с кремом, но хоть читай, о чём была речь. И представляй, что твоя точка зрения не единственная. И даже не единственная массовая.Всё, что здесь наговорено, не делает из обёрнутого питоном openblas (ну, к примеру; или из openmpi) ни на грош более удобного или полезного продукта. Только меньше. После этого все прочие разговоры это... ну я не пойму даже
>>практику западных инженерных колледжей
> то-то там на питон все так фапают (и я имею в виду
> преподавательский состав, а не студентов). Не путайте инженерные задачи с информатикой.Удивлю -- инженерные задачи ещё и поважнее "информатики". ТолковыйИнженерный
>[оверквотинг удален]
>>обёртка почти всегда работает хуже оборачиваемого
> я даже не защищаю питон, однако слышать его критику от человека, по-видимому,
> совершенно не разбирающегося в вопросе, достаточно странно. Не то чтобы таким
> можно было что-либо доказать в принципе. Можно согласиться с тем, библиотеки,
> интегрируемые в питон, порой обладают меньшей гибкостью (по сравнению с тем
> же плюсовым апи), но зачастую это без проблем решается тем, что
> принято называть "monkey patching". Т.е. возможность получить требуемое поведение (если
> оно необходимо) имеется даже тут. Но смысл то как раз в
> том, что все доступные фичи оборачиваются в приятный и удобоваримый формат,
> пригодный для использования.
> ну это уж совсем глупость - как раз благодаря питону и заходят
> все эти додиез с рабями и джавами с плюсами без каких
> либо излишних трудностей. Изучать программирование без жёсткой привязки к объектности
> и реальной жизни = пустая трата времени.Открытие века. Даже два.
Всё, что здесь наговорено, не делает из обёрнутого питоном openblas (ну, к примеру; или из openmpi) ни на грош более удобного или полезного продукта. Только меньше.
Напомню, был (недостоверный) начальный посыл -- "на питоне много научных библиотек".
Поправка была в таком духе -- "преимущественно обёртки, и как таковые не должны засчитываться".После этого все прочие разговоры это... ну я не пойму даже -- к чему? В огороде бузина, где-то ещё monkey patching.
>>практику западных инженерных колледжей
> то-то там на питон все так фапают (и я имею в виду
> преподавательский состав, а не студентов). Не путайте инженерные задачи с информатикой.Не знаю их сексуальной жизни, кто на что "фапает", но учебные программы открыты. Тонны литературы и готового кода (сейчас я говорю о матлабе).
И удивлю, наверное -- инженерные задачи это ещё и поважнее, чем "сто оттенков"информатики". Инженеры решают задачи, нужные всем, в отличие от компьютер-сайентологов.>>обёртка почти всегда работает хуже оборачиваемого
> я даже не защищаю питон, однако слышать его критику от человека, по-видимому,Старина, ты себе люби питон или трубочки с кремом, но хоть читай, о чём была речь. И представляй, что твоя точка зрения не единственная. И даже не единственная массовая.
>Если посмотреть на практику западных инженерных колледжей, так там зачастую первый (и иногда единственный) язык это матлаб.Разница ещё и в том, что Python бери и используй кто угодно, а за Matlab изволь забашлять и немало. Или в России Matlab бесплатный как Венда? ;)
>>Если посмотреть на практику западных инженерных колледжей, так там зачастую первый (и иногда единственный) язык это матлаб.
> Разница ещё и в том, что Python бери и используй кто угодно,
> а за Matlab изволь забашлять и немало. Или в России Matlab
> бесплатный как Венда? ;)Во-первых, мы говорим о получении значимого результата.
Причём здесь бесплатность или свободность?
Во-вторых, можно взять Октаву. Графики не будет, и решения параллелизации, возможно, потребуют доработки (не смотрел давно, как поживает австралийское многоплатформенное решение), но собственно расчётные модели должны работать.
> на питоне. Про js не знаю. На питоне проще думать об
> алгоритме при обработке каких-то данных т к из синтаксиса 5 слов
> примерно нужны, а в "баше" все это время займет изучение синтаксиса
> awk =)Пропаганда. )) Пять слов питона ещё запомнить надо, ведь там всё так оригинально (удавалось исполнить на нём не самую тривиальную механизацию для ОО, но всё равно не возьмусь, никуда не заглядывая, написать цикл с элементами массива, разборкой-сборкой строк и проверками условия).
В то же время синтаксис у awk как у Си, и единственная сложность с ним - это запомнить, что BEGIN и END будут исполнены так, как решила тройка, а не так, как полагает "естественным" оператор :)))
>А смысл что-либо делать на питоне?Тот же что и для любого другого ЯП :)
>Кому реально он нужен?Тому, кто делает.
>Только не надо про bigdata, которая на Java/Scala/Clojure,и на питоне - тоже :)
>про ML, который на R, Matlab, Julia,и на питоне - тоже :)
>администрирование, которое на Rubyадминство на ребе?!?!?! не нюхай клей, нет такого! :)
Вот питон во всех линуксах - предустановлен, а ребе надо лапками ставить или по зависимостям прилетит.
>и пр. области, не имеющие к питону отношенияи на питоне - тоже :)
Логики тут нет, да :) Но что-ж поделаешь? Вон - на жЫсЫ - корпоративные системы карапузы пишут 8-о ... 21-век, ***** и немедленно выругался!(С)
> админство на ребе?!?!?! не нюхай клей, нет такого! :)Puppet, Chef. Со вторым лично не знаком, но первый по возможностям конфигурирования и валидации на этапе до запуска выглядит лучше чем гвидонический АнсибОль.
Хотя если честно, при всей моей нелюбви ко гвидону, ЯП у которого инструмент сборки называется "грабли" (rake) вызывает ещё больше нелюбви, как по понятности кода, так и по ресурсоёмкости.
На выходе тормозят они примерно поровну, но у ансиболи нет зависающего агента и центрального сервера регулярно опухающего от нагрузки (да, есть набор костылей которыми можно это обойти).
В общем, и то убого, и другое убого.
Кроме паппета то в общем практически нигде и не встречается.
А вот тулз которые бэкэндом питон используют полно. Так что изначально автор попытался просто выставить ситуацию в выгодном ему свете.
И стоит добавить что администраторы частенько пишут приложения именно на python, потому что это более гибко чем на баше, и проще и читабельнее чем на перле. И вот не припомню случая чтобы кто то взял и написал что то на руби. Одной из причин этого - не так уж много народа умеют на нём писать, да и синтаксис спорный.
> Кроме паппета то в общем практически нигде и не встречается.Согласен, но тем не менее он занимает заметную долю рынка. Ну и Chef же.
> И стоит добавить что администраторы частенько пишут приложения именно на python, потому
> что это более гибко чем на баше, и проще и читабельнееГибко - да. Читабельнее - чистой воды вкусовщина. Меня например выворачивает от ступенчатого синтаксиса в котором не вдруг поймёшь конец это блока, или вот там спустя пять пустых строк продолжение. Не говоря уж об истории "один таб == 8 пробелов" и вытекающими.
Другое дело что за время развития перла понаписали столько совершенно невменяемого г***кода (при чём в CORE модулях), что теперь на него многие кивают со словами "о ужасный Perl!".> И вот не припомню случая чтобы кто то взял и написал что то на руби.
Я как минимум один знаю, при чём в одной крупной и известной российской IT компании. Но в целом оно конечно скорее исключение чем распространённый случай. А синтаксис там - да, из более-менее распространённых языков сложно придумать что-то более вырвиглазное.
> Согласен, но тем не менее он занимает заметную долю рынка. Ну и Chef же.С Chef мало знаком, а puppet значительно сдвинул ansible, который уже написан на python, и модули для него пишутся так же на python.
> Гибко - да. Читабельнее - чистой воды вкусовщина. Меня например выворачивает от ступенчатого синтаксиса в котором не вдруг поймёшь конец это блока, или вот там спустя пять пустых строк продолжение.
Ну пожалуй да, вкусовщина. Был у меня коллега который с удовольствием писал на перле, но всей душой ненавидел python.
> Не говоря уж об истории "один таб == 8 пробелов" и вытекающими.
1 таб - 4 пробела. И проще вообще не использовать таб - и проблем нет.
Но вообще я в целом согласен.
> Ну пожалуй да, вкусовщина. Был у меня коллега который с удовольствием писал
> на перле, но всей душой ненавидел python.
>> Не говоря уж об истории "один таб == 8 пробелов" и вытекающими.
> 1 таб - 4 пробела.Вот именно про эту историю я и говорил! :)
Попробуйте запустить в 2.7 например:
if True:
print "Hello spaces!"
print "Hello tab!"В третьей строке один таб, во второй - 4 пробела.
А теперь добавьте во вторую строку ещё 4 пробела и запустите ещё раз.
Спутать форматирование кода с логикой - эпический бред на мой взгляд.А табы удобней тем что например можно в начале строки вставлять символ комментария и при этом закомментированный код не сползает вправо.
+1Таб - это же именно символ индентации. Но в Питоне, увы, использовать его слишком опасно, поэтому только пробелы.
Тут хочется вставить свои 5 копеек по поводу python и бэкенда. Имел я удовольствие на своём сервере раскатать тасктрекер Taiga (https://taiga.io). Бэкенд на Python, фронт-енд на AngularJS. То есть это реальное не слишком масштабное web-приложение на Python. Проблемы, с которыми я столкнулся:
-- требуется установка питона определённой версии, кучи каких-то пакетов конкретных версий и дополнительных утилит, в которых чёрт ногу сломит. Короче говоря, задолбаешься раскатывать;
-- ресурсов сие чудо пожирает непомерное количество. Во-первых, эта гадость пожирает 2Гб оперативки через пару часов работы. Во-вторых, походу там где-то течёт память, поэтому эта цифра день ото дня увеличивается;Параллельно на сервере стоял GitLab. Он на Ruby. Когда репозиториев и юзеров становится нормальное количество, всё время что-то отваливается. То права групповые перестают выставляться, то ssh-ключи отпадают, то ещё какая-то чушь. Причём, рестарт сервиса решает эти проблемы. Ок, спишем это на криворукость разработчиков, хотя что-то мне подсказывает, что кривые руки всё-таки у разработчиков самих рубей. Но память тоже подтекает. Хоть и не так жёстко, как в тайге.
Я это всё к тому, что Ruby и Python на бэкенде -- это очень непросто вопреки сложившемуся мнению. Я знаю пару специалистов, которые умеют готовить те же Ruby, но делают они это за немалые деньги. Говорить о простоте или дешивизне не приходится вообще.
В общем, так и есть. Не просто. При установке библиотек может быть тот ещё квест.
Идёт нечто с исходниками на Си, а они не собираются, хоть тресни.
Начинаешь искать готовое, а оно под конкретную версию Питона,
начинаешь чуть ли не в бинарниках HEX редактором исправлять.
Другое дело, что множество потребностей в Питоне довольно простые и установка библиотек обходится стандартным PIP без квестов и извращений.
Так-то оно так. Здорово, когда всё через pip затягивается. Но тут есть 2 момента.
Первый -- это то, что хорошо в теории не всегда так будет работать в практике. Реальные приложения среднего размера уже начинают требовать танцев с бубном, как тайга. В идеале разработчикам в этой ситуации нужно собирать свои репозитории для разных серверных дистрибутивов. Это не так просто, потому что их нужно поддерживать, обновлять воврем и тп. Это человекочасы, то есть дополнительные затраты. Ну и не очень красиво, когда ты в систему тянешь полностью свои библиотеки других версий. Это лишнее дублирование, но для энтерпрайс-коробки сойдёт.
Второй -- по факту, если ты делаешь обёртку над библиотеками сторонних разработчиков, то зависишь от этих разработчиков. А если у них в сишной библиотеке течёт память, а они её не фиксят? Придётся это в конечном счёте делать за них. А это уже необходимость иметь разработчиков на другие языки. И хорошо, если сторонние разработчики вообще не будут твои пул-реквесты игнорировать.
Так спору же нет. У питона куча недостатков. Не говоря уже о том, что он медленный и он интерпретатор.
Зато закостылить какое-нибудь специфическое приложение сложностью в 1 человеко-день, милое дело.
Причём этот человек не является профессиональным программистом.
То что питон тащат в какие-то сложные и большие проекты, это да, очень спорно.
> Зато закостылить какое-нибудь специфическое приложение сложностью в 1 человеко-день,
> милое дело.
> Причём этот человек не является профессиональным программистом.К счастью сейчас это же позволяет делать Golang, на выходе получаем быстрый и экономичный (на фоне интерпретируемых ЯП) бинарь который взлетит практически везде и не потребует всосать пол интернета.
И я надеюсь он успешно утопит как минимум пыхтон.
Ради интереса поставил гоу. Честно говоря, выглядит сложнее питона.
С 25 летним любительским опытом закостыливания. Сначала на бейсике, потом на паскале с ассемблером, затем дельфи, затем перл. С кратковременными вкраплениями лисп, пролог, пхп. Плюс конечно хтмл, цсс, джаваскрипт. Перл в итоге сменил на питон.
Да, именно та самая малоприятная ситуация, когда не дело делаешь, а занимаешься многочасовыми тратами времени чтобы разобраться как облачить задумку в синтаксис языка.
У голанга он нифига не интуитивно понятный.
А на питоне полтора года назад взял и начал писать, легко и непринуждённо.
> админство на ребе?!?!?! не нюхай клей, нет такого! :)
> Вот питон во всех линуксах - предустановлен, а ребе надо лапками ставить
> или по зависимостям прилетит.Руби как раз предустановлен везде. Причем у руби не столь важно какая версия. 1.8 уже нигде не ставят. А вот питон - преимущественно 2.7 по умолчанию
> Руби как раз предустановлен везде.Везде, это где, в вашей убунте или что там у вас? В Debian и CentOS его по умолчанию нету, наверное потому что это малораспространённые дистры, не хипстерский мейнстрим.
В CentOS Руби по умолчанию есть
"Есть в пакетах" и "предустановлен" две большие разницы. Он там есть, но не предустановлен, в отличии от гвидона.
У Centos собственные скрипты администрирования на питоне 2.7. Думаю, большинство современных питонюков будет кричать что так нельзя. Кстати, а есть ли с ней более новые питоны?.....> "Есть в пакетах" и "предустановлен"
Не большая разница, если а) выбираем при установке б) набираем yum install ruby и всё ставится.
Большая разница, если надо подключать дополнительные репозитории. Но в случае Руби, он идёт в базовом комплекте.
Если вы не видите технической разницы между "есть в пакетах" и "предустановлен", то могу только посочувствовать. И обратить внимание на то, что я поправлял только утверждение "предустановлен везде".
>набираем yum install ruby и всё ставится.... и вдруг обнаруживает что в ваш sudo никакой yum то и не прописан :) Ибо нечего тут! Сплошь и рядом в кровавом, но детей по КЗОТу им нанимать нельзя, потому то ты и не знаешь :)
>>Только не надо про bigdata, которая на Java/Scala/Clojure,
>и на питоне - тоже :)Ну это уж откровенная ложь. Несмотря на то, что его впихнули где только можно, годится от только для запуска задач, а не для функций обработки. Не место питону там, где нужна скорость. Да и вообще ему не место в современном программировании. Как учебный язык для тех, кому реально не надо ничего писать - да, годится.
Питон в больших данных - примерно как в анекдоте про блондинку, которая делает мужей миллионерами. Она просто выходит за муж за миллиардеров, через пару месяцев они становятся миллионерами....
>место питонутолько вот питон легко и непринуждённо взаимо-интегрируется с си где это нужно. Упс. И сам по быстродействию он отстаёт только от джаваподелий (что и логично).
>>место питону
> И сам по быстродействию он отстаёт только от джаваподелий (что
> и логично).А также Руби, JS и всему чему только можно. Что и логично.....
Назовите какой-нибудь широко используемый скриптовый язык, который не интегрируется легко с динамическими системными библиотеками>> только вот питон легко и непринуждённо взаимо-интегрируется с си где это нужно.
ок... Проинтегрируйте в питон следующий C-код
void main() {
puts("Hallo Welt!");
}
Только факты: часть software для Ubuntu и других дистрибутивов пишется на Python.
> Только факты: часть software для Ubuntu и других дистрибутивов пишется на Python.ok. Берём OpenSuSE и пытаемся найти скрипты на питоне.... Но почему-то обнаруживаются Руби-скрипты....
Вторая попытка. Берём MacOS... И находим brew как основной пакетный менеджер.... написанный на руби.....
> Вторая попытка. Берём MacOS... И находим brew как основной пакетный менеджер.... написанный
> на руби.....Под Mac есть ещё MacPorts. Он ни C и Tcl вроде бы. Хотя у меня искаропки в системе стоит ruby 2.3.3p222 (2016-11-21 revision 56859) [universal.x86_64-darwin17]
> Кому реально он нужен?К сожалению, systemd преимущественно на нём написан и без него уже ни как. :-(
>Qt
>PythonПайтон и Кутэ? Да это же чемпионы тормознутости, страшно подумать, ЧТО из этого получится.
Windows 10
Pyndows 13
Qt-то в каком это месте тормозной?
> Qt-то в каком это месте тормозной?После написания бизнес-логики на питоне, ясное дело, любая прога с Qt только в качестве UI будет тормозной....
Qt в связке с Python тормозной.
И при этом до всяких модных файрфоксов на растах ему ещё тормозить и тормозить... а по пожиранию ОЗУ и вовсе не догнать
> И при этом до всяких модных файрфоксов на растах ему ещё тормозитьНу не надо. Последний Firefox летает 🚀
Включать пробовал? Мне с 16Гб ОЗУ подолгу уже работать было нифига не комфортно, пришлось ещё докупать.
На ноуте 6 гигов, всё отлично, в совокупности с кедами и Qt Creator с шлангом больше половины памяти редко поднимается.
Тормоза интерфейса окончательно пропали когда из него окончательно выкинули гтк2. Может с видеокартой проблемы? Ну остальное как повезёт, парсер и жс могут подлагивать в зависимости от задач. Про 16 гигов это что-то гон - только хром может 20 гигов на 1 вкладку сливать.
> Включать пробовал? Мне с 16Гб ОЗУ подолгу уже работать было нифига не
> комфортно, пришлось ещё докупать.Как бывший гентушник могу сказать, что общая отзывчивость интерфейса может заисеть от того, с какими патчами собрано ядро. Особенно на системах, где ресурсов немного. В своё время удивился этому факту. Так что здесь сложно кидать камни в огород кого-то конкретного.
Да и жрёт вполне вменяемо
Типа "свиснула и улетела"?
Конечно, чтобы нарисовать пункто-цифровой график мне нужно с головой окунуться в сишную ООПу. И график у меня будет летать и сам я от ЧСВ буду везде писать "не нужно".
> чтобы нарисовать пункто-цифровой график мне нужно с головой окунуться в сишную ООПуЗачем?
Ну и ООП в C++ куда привлекательнее той же Жабы, где даже поддержки операторов нет.
Чтобы рисовать график из *любого* языка программирования, достаточно выучить на этом языке форматированные стандартные потоки. И язык пакета гнуплот (или аналога, это уж кто что).
Зачем в R гнуплот?.... И откуда в нём потоки?....
> Зачем в R гнуплот?.... И откуда в нём потоки?....Некорректные вопросы. Потоки в R от бо^W операционной системы и среды его исполнения. Ну, а "зачем в нём гнуплот"? Во-первых, не "в нём", а в конвейере с ним. А "затем", чтобы не грузиться только ради него одного особенностями его эранутой граф. библиотеки.
Хе... это ты ещё в судоку на эрланге с виксвиджетс не играл )))
Быстрее и легче QML для GUI нет ничего. В Qt накладные расходы везде стремятся к нулю. Тормознутость - это точно не про Qt.
Как-то так
pip install --index-url=http://download.qt.io/snapshots/ci/pyside/5.9/latest/ pyside2 --trusted-host download.qt.io
И вроде они стараются не ломать совместимость с 5.6
Qt сильно привязан к C++, биндинги к нему делать сложно. Захотели высокоуровневый декларативный язык для быстрой разработки приложений (QML) — в результате сделали еще один отдельный тулкит со своим отдельным набором виджетов, вернее, даже с двумя отдельными наборами виджетов — Qt Quick Controls 1 и 2. То есть с Qt сейчас поставляется два отдельных инструментария для разработки интерфейсов с тремя отдельными наборами виджетов. Это какое-то жуткое месиво.Вот чем GTK лучше, так это тем, что у него своя объектная система (GObject) не являющаяся частью языка программирования, что сильно упрощает адаптацию тулкита к различным ЯП и создание новых вокруг существующей объектной системы (Vala и Genie).
Ну если прикручивание всяких костылей проще в GTK, то да, в этом плане он гораздо лучше чем QtWidgets. А со всем Qt его не сравнишь, не дотягивает малость.
GTK можно сравнивать с QtWidgets (или как правильно этот компонент называется), а не со всем Qt
Ну я это и написал выше твоего сообщения.
> Ну я это и написал выше твоего сообщения.я отвечал на:
> А со всем Qt его не сравнишь, не дотягивает малость.
в том плане, что весь Qt надо сравнивать с gobject.
это как если бы ты сказал, что QtWidgets не дотягивает до Qt.
Qt отказались от виджетов в пользу QML, именно потому что виджеты непомерно жрут память и процессор. Но виджеты не умерли, их продолжают использовать повсеместно. И не только QWidget, но и Qt Quick 1. И по сути никого не волнует, что это всё deprecated, но все продолжают ныть, что работает не быстро.
Если хотите легкий, очень быстрый интерфейс, с OpenGL ускорением - надо использовать Qt Quick 2.
> легкий, очень быстрый … с OpenGL ...
> Qt Quick 2.Как можно сделать столько ошибок в названии imgui (или nuklear)?
https://github.com/vurtun/nuklear
https://github.com/ocornut/imguiPS: для тех, кто подумывает отважно кинуться на защиту любимейшего тулкита, прошу еще раз обратить внимание на выделенные "легкий, очень быстрый" и отсутсвующие "с уже готовыми кросплатформеными абстракциями, позволяющий с минимум кода сваять 'сделать все зашибись!'" ;)
С чего это вдруг QtWidgets deprecated? QML начали развивать как ответ на Aero и XAML, но это не значит что виджеты тормозили. Вот чему тормозить к примеру в кнопке? А вот если добавлять модные спецэффекты, то да, программный рендеринг уже не годится. Поэтому разработчики Qt решили не ломать стройную структуру виджетов и параллельно с нуля создать что-то новое, более подходящее под спецэффекты.
>с OpenGL ускорением - надо использовать Qt Quick 2А что им мешает QtWidgets тоже перевести на ускорение OpenGL?
GTK - это по сути те самые тормозные виджеты (QWidget).
> Вот чем GTK лучше, так это тем, что у него своя объектная система (GObject) не являющаяся частью языка программированияЭто называется велосипедом. Причем отнюдь не Scott, а скорее Кама или Школьник.
подержка питона в кьют без дополнительных зависимостей? Класс, ждем ебилдов
Однокнопочное приложение на таком бутерброде технологий (мегатормозной Qt + гипертормозной Python) запускаться будет секунд десять. А потом ещё две секунды отрисовываться кнопка.Хорошо, что это проект уже является мертворождённым. Много ли вы знаете десктопных (хотя проще: любых) приложений на PyQt или PySide? Адекватные разработчики никогда не выберут эти по делки. Они выберут GTK+ и PyGtk. Потому что тулкит GTK+ даже в связке с гипертормозным Python куда как более юзабелен, чем поделки-привязки к Qt. Количество приложений подтверждает полностью мои слова: http://www.pygtk.org/applications.html
Выбирайте свободные фреймворки, а не поделки с мутным проприетарным прошлым.
Дуплик, пожалуйста, хватит уже нести чушь о мифической тормознутости Qt, это уже не смешно и не интересно, ну серьёзно.А на Питоне мало кто в здравом уме будет делать гуи в целом. Разве что, уже нет некий скрипт или математика, куда просто нужен гуй без лишних хлопот
Мне тоже когда-то так казалось, а потом одноядерный стоваттник из прошлого тысячелетия был поменян на актуальный и это всё прошло. Вот что тормозит так это гуй на джаве (и не только на стадии запуска). Что особо удивительно, так это то что сама то джава не тормозит (пока гц не наступит).
Тормоза жабы, они такие.
Если обложиться профайлерами, долго и нудно устранять узкие места, тюнить GC, то никаких тормозов нет, при условии прямых рук и кода средней кучерявости.
Но это долго, дорого и не всем нужно. По этому тормоза есть.
лично у меня о любых бидоновских гуйных приложениях сформировалась четкая ассоциация с абсолютно нечитаемым стектрейсом, который часто выводится в случаях, когда бидоно-гуишное приложение в очередной раз соизволит упасть.Вот прямо если видишь, что приложение на бидончике, то тут же понимаешь: будет тормозить и частенько ложиться с нечитаемым стектрейсом. Ассоциация примерно как BSOD у еще одной проприетарной поделки -- Microsoft Windows.
Но свидетели непадающего супервысокоскоростного гиперпитона со мной, разумеется, не согласятся.
>> Много ли вы знаете десктопных (хотя проще: любых) приложений на PyQt или PySide?А что, гугл тоже запретили? У моего провайдера пока работает
Я вот ни одного на PyGtk не знаю. Посмотрел список. Там что-то есть живое? А полезное?
потому что PyGTK это биндинги к мёртвому GTK2, для GTK3 используются биндлинги для glib-а (gobject-introspection), выше в трэде кто-то рассказывал про это подробнее уже
биндинги
Чуваааак! Выжыхай! Я даже в тредэ игори, написанные на питоне и кутэ играл. Last days of gaya, вроде называлась одна из них. Она даже на дешёвом (доступном мне в те годы) железе шла без лагов.
Vampire: The Masquerade - Bloodlines ещё. Особые извращенцы в том же качестве джаву в те же годы в качестве скриптоты пихали, получалось не очень, но работало. Это всё явно не про производительность.
Извините, стоило упомянуть что The Fall так безбожно лагала, что было совершенно неиграбельно (хотя говорят там нереальное количество багов было) и VTMB тоже проседала местами, по виду тоже на логике. А та с джабой нет. (Chrome кому интересно, больше не продаётся в стиме - не знаю где возьмёте)
Мегатормозным Qt вообще никогда не был, это с++, нативная производительность. Были проблемы с виджетами, но уже давно предложено решение в виде qt quick 2. А тормозят интерфейсы потому что многие рукожопые обезьяны продолжают использовать виджеты, хотя везде пишется этого не делать. Виджеты даже выделили в отдельный модуль, который нужно подключать вручную. Но всеравно многие продолжают гнуть свою линию, и сраться на форумах о "тормознутости".
Этот новый чудный мир.
сто лет в обед с самого начала еще до покупки существовал квик тулс для среды python. только я бы всех любителей его не сильно радовался. он потому и open source что не держит секретов это еще в 2007 году была шумная история на счет безопасности. все кто ей занимался демонстративно ушли - потому что физически невозможно...
> Смена имени пакета призвана предоставить цельное решение для использования Qt в Python-приложениях, включающие сопутствующие сервисы, такие как оказание коммерческой технической поддержки.100 лет? Бидон конечно давно форсят, но это уже новый уровень.
Быстрый Qt компенсирует тормознутый Python и выйдет нечто среднее, более менее приемлемое для потребления.
Тормознутость - это GIL или что-то еще?
Pypy вполне неплох, успехов ему.
Разработка интерфейсов на QML такая же быстрая, как разработка ПО на Python. Думаю они будут неплохо сочетаться. Тем более у питона есть явные проблемы с производительностью, а с гуи вообще беда. QML значительно ускорит это дело.
Ни один язык не вызывает столько эмоциональных криков на opennet как питон. Верный признак того что стоит его изучать. Знание поговорки про мух не делает количество экскрементов на Земле меньше. Так зачем переживать?