LINUX.ORG.RU

Python Image Library и ее разработчики совсем все О_О?

 


0

1

ОС mint XFCE 19.3

$ cat test-imaging.cpp

#include <Imaging.h>
#include <Imaging.h>

int main(){ return 0; }
$ g++ -I/usr/include/python2.7 test-imaging.cpp
In file included from test-imaging.cpp:2:0:
/usr/include/python2.7/Imaging.h:81:3: error: conflicting declaration ‘typedef struct ImagingMemoryBlock ImagingMemoryBlock’
 } ImagingMemoryBlock;
   ^~~~~~~~~~~~~~~~~~
In file included from test-imaging.cpp:1:0:
/usr/include/python2.7/Imaging.h:81:3: note: previous declaration as ‘typedef struct ImagingMemoryBlock ImagingMemoryBlock’
 } ImagingMemoryBlock;
   ^~~~~~~~~~~~~~~~~~
...

Начиная с 17 убунты оно уже не компилировалось из коробки, приходилось убирать из Imaging.h лишний typedef. Как оно попало в репозиторий в таком виде я ХЗ. Но что бы полениться воткнуть #pragma once - это я вообще не знаю кем надо быть… О_О

Вопрос - чем бы ее заменить? Хотя я чую придется вообще весь стек менять;-(

★★★★★
Ответ на: комментарий от vvn_black

Мне бы не хотелось это тут обсуждать, но я бы лучше закопал третий питон вместе с теми кто сломал обратную совместимость. За такое надо бить канделябром по пальцам. Я не вижу никаких существенных преимуществ у py3 которые могли бы оправдать слом совместимости - все годные плюшки которые там есть можно было бы прикрутить и в py2.

AntonI ★★★★★
() автор топика
Ответ на: комментарий от AntonI

все годные плюшки которые там есть можно было бы прикрутить и в py2.

Два чая этому господину.

anonymous
()
Ответ на: комментарий от AntonI

Йепрст, у меня довольно много кода на py2 и времени на его перевод на py3 вообще нет.

по-моему уже было дано много лет на это.

anonymous
()
Ответ на: комментарий от AntonI

Как раз наоборот, периодический слом совместимости в целях избавления от костылей - это лучшее что может случиться с языком программирования, и давно необходимо, например, C++, и многим другим языкам. А вот закапывать живьём со сломанными пальцами надо тех кто за 10 лет не нашёл времени на изменения большую часть которых можно сделать, грубо говоря, sed’ом, даже не прибегая к огромному объёму инструментов в виде всяких 2to3, six, future и миллиона других конвертеров и полифиллов. Вы не только 10 лет пинали *, но ещё и настаиваете что так и должно быть, поэтому от всей души желаю вам максимальных стаданий.

slovazap ★★★★★
()
Ответ на: комментарий от AntonI

но я бы лучше закопал третий питон вместе с теми кто сломал обратную совместимость

но, к сожалению, закапывают тебя

anonymous
()
Ответ на: комментарий от AntonI

Я хотя на python не пишу, но согласен полностью. Так жидко обгадить язык поломкой обратной совместимости - это капец просто.

В результате сейчас почти все вынужденно поддерживают две версии - для второго и третьего питона.

Qasta
()
Ответ на: комментарий от slovazap

Как хорошо что в большинстве языков сохраняют совместимость.

Тот же freepascal можно учить по книгам 90 годов и примеры соберутся.

А для избавления от костылей есть другие методы. Например, в Visual Studio проект по-умолчанию просто не соберётся если используется некоторые С функции, которым есть лучшие аналоги, или С++ функции которые deprecated. Но если очень нужно, то просто меняются флаги сборки и всё собирается, и не нужно переписывать рабочий код.

Вот это правильное решение, с одной стороны в новом коде не будет легаси, с другой не нужно переписывать код без необходимости.

fsb4000 ★★★★★
()
Ответ на: комментарий от fsb4000

Как хорошо что в большинстве языков сохраняют совместимость.

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

stasolog
()
Ответ на: комментарий от AntonI

но я бы лучше закопал третий питон

закапывай

все годные плюшки которые там есть можно было бы прикрутить и в py2

прикручивай

anonymous
()
Ответ на: комментарий от AntonI

Программисты почему-то думают, что программы должны вечно обновляться, вечно меняться и подстраиваться, да еще и переписываться периодически с нуля. Очень такая текучая нестабильная сущность эти программы. Может быть, в языках C и C++ это менее выражено, чем в остальных. Страдание и боль в этих ваших питонах и подобных.

dave ★★★★★
()
Ответ на: комментарий от mittorn

Серьезно? Даже самый ленивый узбек обдает заварочный чайник кипятком третьекурсник пишет #pragma once/#ifndef … в начале своих хидеров. Сфига ли в такой замечательной библиотеке которой уже дцать лет так не делают? Причем судя по всему у них это принципиальная позиция, бегло пробежался, нигде у них не нашел.

Типа проблемы юзера ос множественными включениями разработчиков не волнуют, пишите хидер-обертку если надо?

AntonI ★★★★★
() автор топика
Ответ на: комментарий от dave

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

Я помню как в гнуплоте сломали совместимость - раньше было ‘set data style’ потом стало ‘set style data’ (или наоборот). Я в голос орал, у меня все скрипты работать перестали…

Хотите че то поломать шо аж кушать не можете - сделайте новый ЯП.

AntonI ★★★★★
() автор топика
Ответ на: комментарий от AntonI

PIL УГ, потому вместо него гружу libxxx.so средствами пыхтона

mittorn ★★★★★
()
Ответ на: комментарий от fsb4000

Тот же freepascal можно учить по книгам 90 годов и примеры соберутся.

Паскаль мёртв - на нем не пишется новый софт и уже забыт старый, абсолютно всё равно ломает он совместимость или сохраняет.

или С++ функции которые deprecated

Вы наверное не в курсе развития C++, всего вала новых «фичей» которые не решают всех проблем которые призваны решить и создают новые, при этом сложность языка неуклонно растёт. Депрекейт полутора фич типа auto_ptr это жалкая капля в море.

Вот это правильное решение, с одной стороны в новом коде не будет легаси, с другой не нужно переписывать код без необходимости.

Нужно-нужно. Не бывает кода в вакууме, код всегда в экосистеме, и если он за ней не успевает то гниёт и ломается. Например, новые версии gcc переходят на новые стандарты по умолчанию, код ломается. Начинают лучше оптимизировать, поэтому вылезают ранее незаметные UB, код ломается. С указанием старого -std или с использованием старой версии компилятора код перестаёт собираться с новыми версиями зависимостей, которые старый стандарт уже не поддерживают, в итоге остаётся только тратить кучу сил на поддержку старой версии всей экосистемы (компиляторы, зависимости, может даже ядро), восстанавливать там совместимость с новым кодом где нужно, чинить уязвимости, и т.д. Ну либо выкинуть легаси. Как думаете что происходит на практике?

slovazap ★★★★★
()
Ответ на: комментарий от slovazap

Я так и не понял, как связаны лучшая диагностика в новых компиляторах и развитие стандарта. При неизменном стандарте, точно так же вылезали бы незаметные ранее UB.

при этом сложность языка неуклонно растёт

4.2 сложность языка неуклонно падает.

fsb4000 ★★★★★
()
Ответ на: комментарий от fsb4000

сложность языка неуклонно падает

Да ты шо? uniform initialization - то хоть научился пользоваться? А новой из 20 стандарта?

slovazap ★★★★★
()
Ответ на: комментарий от slovazap

Там всё легко, и становится ещё легче. Иди наверни простейших шаблонов на С++98, а я с мегасложным constexpr останусь.

fsb4000 ★★★★★
()
Ответ на: комментарий от slovazap

Старые приложения, которые просто работают, тоже закопать, потому что язык/фреймворк устарел?

Только один из многих примеров: есть утилита FSLint. Её удаляют из репозиториев, потому что она написана на Python 2.x, и использует python-gtk2.

С точки зрения пользователя — она работает и выполняет свои функции. Зачем её удалять? Шансы, что кто-то возьмётся переписать — малы. После удаления в репозиториях просто нет свободной адекватной альтернативы с GUI.

Периодический принудительный слом совместимости в целях избавления от костылей — это худшее, что может случиться с ОС общего назначения, особенно для десктопов. В результате выбрасывается многолетний труд, просто потому что эстетика для некоторых важнее практичности.

Но те, кто ломает и выбрасывает старый код, не учитывают, что потратившие своё время энтузиасты и компании вряд ли соглашались поддерживать 10-20 лет свои продукты, портировать на новые версии языков/фреймворков, следить, не появились ли регрессии, особенно вследствие притянутых за уши причин вроде нового синтаксиса или переделывание API без сохранения совместимости с предыдущими версиями.

P.S. Скорее всего, с момента выкидывания Python2, придётся смотреть в сторону контейнеров для приложений, чтобы сохранить рабочее ПО.

Pravorskyi ★★★
()
Ответ на: комментарий от fsb4000

Ну только шаблоны никуда не делись как минимум пока нет constexpr allocator, поэтому у тебя И шаблоны И constexpr. А ты врёшь что стало легче.

slovazap ★★★★★
()

Вопрос - чем бы ее заменить?

ты бы написал точный список своих требований. Есть альтернативы, но откуда ж мы знаем что тебе нужно конкретно :)

former_anonymous ★★★
()
Ответ на: комментарий от Pravorskyi

Старые приложения, которые просто работают, тоже закопать, потому что язык/фреймворк устарел?

Естественно. Если они не слезли с неподдерживаемого языка/фреймворка то они сами по себе неподдерживаемые, а значит уязвимые, никем не тестируемые, но требующие при этом сил на поддержку, и они подведут в самый ответственный момент. Вы будете такой весь в себе просветлённый работает-не-трогай гуру, а потом рраз - и проект перестаёт работать от слова совсем. Гуру, за невозможностью ничего сделать успешно выпинывается, и, что характерно, просто идёт вредить в другую контору, а бизнес потом ищет ему замену за любые деньги, и не может найти, пока сам не развалится.

С точки зрения пользователя — она работает и выполняет свои функции. Зачем её удалять? Шансы, что кто-то возьмётся переписать — малы. После удаления в репозиториях просто нет свободной адекватной альтернативы с GUI.

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

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

Во-первых, не надо путать труд и результат труда. Труд нельзя выкинуть, он уже произведён, и привёл как к появлению непосредственных результатов, так и лёг в основу последующего развития. А результаты - это временное явление, естественно устревающее сразу после своего появления.

Но те, кто ломает и выбрасывает старый код, не учитывают, что потратившие своё время энтузиасты и компании вряд ли соглашались поддерживать 10-20 лет свои продукты, портировать на новые версии языков/фреймворков, следить, не появились ли регрессии, особенно вследствие притянутых за уши причин вроде нового синтаксиса или переделывание API без сохранения совместимости с предыдущими версиями.

Всё у чего не появилось конкурентов или в чём не исчезла надобность, поддерживается и 10, и 20 и 50 лет. А остальное само радо отправиться на помойку, потому что это освобождает силы для более актуальных проектов.

P.S. Скорее всего, с момента выкидывания Python2, придётся смотреть в сторону контейнеров для приложений, чтобы сохранить рабочее ПО.

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

slovazap ★★★★★
()
Ответ на: комментарий от slovazap

Если они не слезли с неподдерживаемого языка/фреймворка то они сами по себе неподдерживаемые, а значит уязвимые

Новые приложения конечно же неуязвимы, и проблем с ними нету. Интересно кстати, что затратней, поиск специалиста для фиксов или постоянное их держание?

stasolog
()
Ответ на: комментарий от stasolog

Новые приложения конечно же неуязвимы

Конечно. Попробуй, например, найти хоть одну уязвимость в /bin/true или /bin/false на Rust’е. Спойлер: ты не сможешь.

Разорванный Флакон

anonymous
()
Ответ на: комментарий от fsb4000

Я так и не понял, как связаны лучшая диагностика в новых компиляторах и развитие стандарта.

Забавно наблюдать, как два адепта спорят о том, кто больше раз выстрелил себе в ногу. Смотрите не затопите соседа снизу своими утечками памяти, а то он врубит неопределенное поведение, и так вам буфер продырявит, что никакой АдресАссенизатор из clang’а не поможет.

Разорванный Флакон

anonymous
()
23 июня 2020 г.
Ответ на: комментарий от slovazap

Python Image Library и ее разработчики совсем все О_О? (комментарий)

Естественно. Если они не слезли с неподдерживаемого языка/фреймворка то они сами по себе неподдерживаемые, а значит уязвимые, никем не тестируемые, но требующие при этом сил на поддержку, и они подведут в самый ответственный момент.

неподдерживаемые, а значит уязвимые

Из первого не обязательно следует второе.

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

Во-вторых, это не значит, что поддерживаемый софт защищен и не имеет 0-day. Превентивная защита нужна в любом случае: ограничение прав, запуск в песочницах.

никем не тестируемые

К сожалению, такое случается и с поддерживаемым ПО. Код пишут быстрее, чем тесты. QA — роскошь для многих свободных проектов. Энтузиасты тестируют в процессе использования.

но требующие при этом сил на поддержку

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

и они подведут в самый ответственный момент

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

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

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

Понимаешь какая штука, весь софт как был написал потому что кому-то нужен, так и поддерживается потому что кому-то нужен.

Чтобы объяснить, почему это не совсем так, придется усложнить объяснение. Есть множество тех, кому софт нужен, множество тех, кто умеет его написать/поддерживать, и множество тех, кто решительно настроен это сделать. В пересечении этих множеств находятся авторы софта и ментейнеры.

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

И здесь тоже пригодится вышеупомянутый пример с множествами. Когда случается, что авторы или ментейнеры теряют возможность сопровождать софт (причин множество: семья, основная работа, новые увлечения, bus factor, выгорание, здоровье), то это не значит, что пропадают пользователи или инженеры, которые хотели бы поддерживать, но пока не имеют возможности потратить n человекочасов.

Если рассуждать, что есть только два варианта: чёрное или белое, нужен или не нужен, то всё просто. На практике есть градации. Например, ПО полезное и пользователям упрощает некоторые задачи или добавляет некоторого комфорта. Но они не готовы организоваться и собрать несколько сотен или тысяч долларов, чтобы нанять фрилансера или того же автора, сделать форк и образовать коммьюнити вокруг него. Это отличается от варианта, когда рабочий доступный софт не используется, потому что никому не нужен. По-настоящему никому не нужен.

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

Если пользователь выполняет свои привычные задачи привычным инструментом, но очередное обновление его ломает — это проблема системы, а не пользователя. Проблема даже не в том, чтобы поддерживали, а в том, чтобы не ломали userspace.

Во-первых, не надо путать труд и результат труда. Труд нельзя выкинуть, он уже произведён, и привёл как к появлению непосредственных результатов, так и лёг в основу последующего развития.

Согласен.

А результаты - это временное явление, естественно устревающее сразу после своего появления.

Тоже согласен. Вопрос во временных рамках: в одном окружении (ОС, язык, фреймворк, библиотеки) результат труда может быть сломан через пару лет, в другом окружении благодаря стабильному API, ABI и прослойкам совместимости результатом труда можно пользоваться и спустя лет 20.

Всё у чего не появилось конкурентов или в чём не исчезла надобность, поддерживается и 10, и 20 и 50 лет. А остальное само радо отправиться на помойку, потому что это освобождает силы для более актуальных проектов.

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

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

Зависит от того, как используется решение. Я не обсуждаю сейчас бизнес, а также я против использования старого неподдерживаемого софта/библиотек на публичных серверах. Но если это оффлайновое ПО, которое просто выполняет свои задачи для пользователя, то что мешает ему выполнять их дальше, кроме как принудительное ломание userspace?

Pravorskyi ★★★
()
Последнее исправление: Pravorskyi (всего исправлений: 3)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.