LINUX.ORG.RU

Логика намеренного несохранения обратной совместимости

 , ,


0

4

И снова я про питон (и немножко про c++ в конце). Установил я значит библиотеку rnnmorph, при попытке использовать ругается:

AttributeError: module 'numpy' has no attribute 'float'.
`np.float` was a deprecated alias for the builtin `float`. To avoid this error in existing code, use `float` by itself. Doing this will not modify any behavior and is safe. If you specifically wanted the numpy scalar type, use `np.float64` here.
The aliases was originally deprecated in NumPy 1.20; for more details and guidance see the original release note at:
    https://numpy.org/devdocs/release/1.20.0-notes.html#deprecations

Благо я уже не совсем зеленый в питоне (хотя и до зрелого далеко еще) и быстренько написал:

import numpy

if not hasattr(numpy, 'float'):
    numpy.float = float

До этого аналогично с int. Заработало!

И чем же они оправдывают:

Using the aliases of builtin types like np.int is deprecated

For a long time, np.int has been an alias of the builtin int. This is repeatedly a cause of confusion for newcomers, and existed mainly for historic reasons.

These aliases have been deprecated. The table below shows the full list of deprecated aliases, along with their exact meaning. Replacing uses of items in the first column with the contents of the second column will work identically and silence the deprecation warning.

confusion for newcomers - о, как. А не confusion ли , если ньюкамеры обламываются о неработающую, по этой причине, либу? Хотя надо сказать, огромное спасибо, что не поленились в сообщение об ошибке в данном месте засунуть пояснение про deprecated.

confusion тут видимо в том, что numpy.int (и float и др.) фактически не приводил тип к numpy, то что это алиас к общепитоньему int, float это действительно могло путать. Но неужто настолько много и часто, что разработчики решили нарочно похерить обратную совместимость, чтобы избежать проблем, пусть и ценой поломаных программ?

P.S. С одной стороны не доволен, с другой, например, в C++ вот такой фокус с полиморфизмом, чтобы на лету поправить класс для подключаемой либы, вряд ли получился бы.

★★★★★

Последнее исправление: praseodim (всего исправлений: 3)
Ответ на: комментарий от anonymous

Любители выстрелить себе в ногу и сейчас могут всего лишь чуть сложнее:

from numpy import int64 as int, float64 as float

При этом, если numpy.int реально было алиасом к просто int не совсем понимаю, что от этого сломалось бы?

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

По сути отпилили костыли.

# Make these accessible from numpy name-space
# but not imported in from numpy import *
if sys.version_info[0] >= 3:
    from builtins import bool, int, float, complex, object, str
    unicode = str
else:
    from __builtin__ import bool, int, float, complex, object, unicode, str
anonymous
()

дык «всё правильно сделали»

т.е. в своё время завели numpy.float и numpy.int из каких долгосрочных архитектурно-стратосферных целей ( али универсализация между py2 py3 вариантами али ещё какая весомая-для причастных причина)

ща отпилили явно не вполне целесообразное - при этом замокать(не вполне точно но ок) вполне в однострок:


(restore:=lambda m,f,frm:hasattr(m,f)||setattr(m,f,frm))(numpy,'float',__builtins__.float)
...

restore(numpy,'пыщь',пощь)
qulinxao3 ★☆
()

если ньюкамеры обламываются о неработающую, по этой причине, либу?

Тут вопрос к разработчикам этой либы. Ради какой великой цели они писали numpy.float вместо float? Просто потому что могут?

CrX ★★★★★
()

Это косяк зависимостей, в requirements.txt не указана конкретная версия numpy.

У питона очень плохое представление об обратной совместимости. Перенести модули, поломать обратную совместимость – вполне нормальное явление.

dicos ★★
()

если ньюкамеры обламываются о неработающую, по этой причине, либу?

Падать и срать малоприятными стектрейсами это основное предназначение петона.

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

Предупреждают за два/три релиза, поменять просто как два пальца /np.float/float/g, проблема нормально поддерживать софт?

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

praseodim ★★★★★
() автор топика
Последнее исправление: praseodim (всего исправлений: 1)
Ответ на: комментарий от CrX

Тут вопрос к разработчикам этой либы. Ради какой великой цели они писали numpy.float вместо float? Просто потому что могут?

Там внутри же сишечка. Видимо была идея реализации своей быстрой реализации флоата, но не взлетело.

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

pandas в данном случае не причем. Это rnnmorph, до этого приключение было с pymorph2, которая три года уже не обновляется.

Там у нее используется модуль inspect, у которого функцию getargspec заменили на getfullargspec и добавили лишнее возвращаемое значение, так что простая подмена не проходит, надо еще args[1:] подставить.

И вот в таком подходе целая философия чувствуется. Чтобы значит все было «по красоте», даже если ломается совместимость, так ведь обычно не сразу, предупреждают.

praseodim ★★★★★
() автор топика
Последнее исправление: praseodim (всего исправлений: 1)
Ответ на: комментарий от praseodim

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

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

Или просто немного другую культуру разработки иметь.

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

К сожалению, под Perl по разным причинам перестали писать много современного кода. Может потому что все же менее читабельный и легкий для начала въезжания в него. Питону же школьников успешно учат.

praseodim ★★★★★
() автор топика
Последнее исправление: praseodim (всего исправлений: 1)
Ответ на: комментарий от praseodim

ну так и ставьте устаревшие версии зависимостей, если хотите продолжать использовать неподдерживаемую либу. А как иначе то? Очевидно, что в одном проекте подразумевается поддержка какой-то конкретной версии библиотеки. Если условная py_module используется в десяти разных пакетах, которые нужны вашей программе, то вы будете вынуждены рекурсивно ограничевать версии всех этих пакетов если хотя бы в одном из них есть ограничение py_module==0.1

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

Perl-среде подобных казусов намного меньше

потому что ни кода, ни развития, лишь одни админы со своим «работает - не трожь». А там, где много людей, бурно развиваются, то либо монструозное джава апи и опять стагнация, либо чаще необратимо меняется апи.

max_lapshin ★★★★★
()

Что с этим не так?

ценой поломаных программ

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

rnnmorph

Автор два года уже ничего не коммитил, неудивительно что сломалось. Зашли ему PR.

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

ну так и ставьте устаревшие версии зависимостей, если хотите продолжать использовать неподдерживаемую либу. А как иначе то?

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

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

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

На тысячу не тысячу, но хотя бы лет на 10 неплохо бы и обеспечивать. В общем-то например в Java или .Net мире так и работает, обратная совместимость часто даже и на 20 лет назад.

Заслали (не я). Автор буквально следующее ответил: «Щас бы в 2024-м использовать rnnmorph» =)) Собственно, свет клином на ней сошелся, он может даже и прав.

praseodim ★★★★★
() автор топика
Последнее исправление: praseodim (всего исправлений: 1)
Ответ на: комментарий от praseodim

Что значит «либа не запустится»? Выражайтесь яснее. Либы не запускают, их импортируют и используют в своем коде. И нет, либы не портятся со временем, не протухают и у них нет срока годности. Что за ерунду вы городите?

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

потому что ни кода, ни развития, лишь одни админы со своим «работает - не трожь». А там, где много людей, бурно развиваются, то либо монструозное джава апи и опять стагнация, либо чаще необратимо меняется апи.

Есть там и код и развитие, хотя сейчас и не быстрое. Однако в Perl-среде было с самого начала принято не просто писать код, а еще и тесты к нему и для новых версий прогонять старые тесты для поиска регрессий. При этом естественно не ломать API. Также в общем-то и в C/C++ экосистеме, пока туда не поналезли кому лишь бы в продакшен на пять минут быстрее.

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

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

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

Что значит «уже установленную»? Как это? В питоне либы устанавливаются не в какое-то шареное место, это не Си. В питоне каждый инстанс питона владеет своим собственным site-packages, запустить(!) уже установленные пакеты(!) другим питоном, это надо очень умудрится. Ты городишь лютую чушь

FishHook
()

Safe bet - если Вы не знаете как что-то там интерпретировать - не нужно даже пытаться. Игнорируйте. Это открывает путь protocol updates going forward.

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

В питоне каждый инстанс питона владеет своим собственным site-packages, запустить(!) уже установленные пакеты(!) другим питоном, это надо очень умудрится. Ты городишь лютую чушь

Ты вообще с питоном работал?

Тебе захотелась библиотеку rnnmorph проверить в работе. Пишешь pip install rnnmorph Спокойно устанавливается без звука. Пишешь

from rnnmorph.predictor import RNNMorphPredictor
predictor = RNNMorphPredictor(language="ru")
ru_predict = predictor.predict(text_ru.split(' '))

И оно валится с трейсом. «Уже установленная».

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

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

Да дело не в Numpy, это просто для примера, причем не худшего, в Numpy хотя бы сознательно депрекейтнули и не поленились в сообщение об ошибке добавить ее причину и разъяснение со ссылкой на сайт разработчика.

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

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

Он не потянул несовместимой версии numpy, он просто установился. И не только он, но и некоторые другие вещи.

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

praseodim ★★★★★
() автор топика
Последнее исправление: praseodim (всего исправлений: 1)

Но неужто настолько много и часто, что разработчики решили нарочно похерить обратную совместимость, чтобы избежать проблем, пусть и ценой поломаных программ?

Что значит «поломанных программ»? Они же не поменяли это в старых версиях, надо полагать.

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

Поломанных - это когда простейший код всего-лишь трехлетней давности валится с ошибками в актуальных в дистрибутиве версиях Python и надо разбираться что и как править.

praseodim ★★★★★
() автор топика
Последнее исправление: praseodim (всего исправлений: 1)
Ответ на: комментарий от praseodim

Ты вообще с питоном работал?

примерно с 2008 года работаю

И оно валится с трейсом.

и какую же «обратную несовместимость» в этот трейс внёс именно питон то? У нормальных людей в проектах зависимости залоканы в том или ином виде lock файлов, в питоне это делается, с помощью, например, Pipenv.lock или poetry.lock или .in файлов. Эта практика не уникальна для питона, такие файлы есть и в npm, и в Cargo и в Gopkg - везде где есть публичный репозиторий библиотек, есть проблема протухших зависимостей и решается она похожими методами. Но до""""ба""ся ты до питона. Сразу видно - специалист

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

Но до""""ба""ся ты до питона. Сразу видно - специалист

Ну может дело еще в том, что в компилируемых языках несовместимости обычно на этапе компиляции еще вылазят. С интепретируемыми в основном дело имел с Perl (да и то он скорее полукомпилируемый) и там, вот честно, несовместимостей куда меньше.

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

Ничего подобного в случае .NET к примеру или Java или Perl. В принципе тоже можно нарваться на несовместимость, но обычно нормально работает даже что-то из нулевых. С C/C++ сложнее, зависит от окружения, если графическое, то вероятно тоже придется воевать с совместимостями, если чисто консольное, то вероятность успешной компиляции и работы много выше.

praseodim ★★★★★
() автор топика
Последнее исправление: praseodim (всего исправлений: 2)
Ответ на: комментарий от praseodim

А с питоном раздражает, что вот берешь питонский ноутбук с какой-то темой

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

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

Так и не доходит о чем я? Я не про опыт как заставить что-то работать, а про опыт, что вообще зачем так любят менять API? Причем, такое ощущение, что просто чтобы по-феншую, по красоте выглядело.

И кстати, виртуальные окружения могут и не помочь, если для работы надо не просто зафиксировать версии каких-то либ, а даунгрейдить поставляемые в комплекте. Т.е., если нужна более старая версия Python вообще.

Вот еще мелкий пример: https://stackoverflow.com/questions/70215049/attributeerror-tfidfvectorizer-o...

На вопрос, что делать с ошибкой объясняют:

When sklearn.__version__ <= 0.24.x use following method

get_feature_names()

When sklearn.__version__ >= 1.0.x use following method

get_feature_names_out()

Можно конечно считать, что версии 0.xxx не стабильные по определению, да.

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

Так и не доходит о чем я? Я не про опыт как заставить что-то работать, а про опыт, что вообще зачем так любят менять API? Причем, такое ощущение, что просто чтобы по-феншую, по красоте выглядело.

А что, этого мало?

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

Мало конечно, если код уже широко распространился.

Для пример как надо проектировать и поддерживать - это, что код на WinAPI из sdk еще для винды 1.0 (1985-го года!) успешно можно было еще в 2015-м (может позже, экспериментировали тогда) откомпилировать. Какое-то косметическое изменение правда все же понадобилось, уже не помню какое, но ерунда совсем. Феншуйщики бы камня на камня уже не оставили бы от того API.

Вот допустим была функция WinExec еще в 1-й винде для запуска программ. Она до сих пор оставлена для совместимости, но уже с начала 90-х следует использовать CreateProcess. (Но можно и WinExec, если хочется). С питоньим подходом WinExec бы уже давно был бы deprecated и убран. Да и CreateProcess бы уже заменили несколько раз на что-то другое.

praseodim ★★★★★
() автор топика
Последнее исправление: praseodim (всего исправлений: 2)
Ответ на: комментарий от praseodim

вообще зачем так любят менять API?

затем, что поддерживать старое очень и очень дорого.

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

Так что за поддержку старого клиент платит СИЛЬНО больше.

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

затем, что поддерживать старое очень и очень дорого.

Речь идет всего-лишь о том, чтобы без совсем острой нужды не ломать совместимость в API, это так дорого? Но, кстати, поэтому поддержка и дорогая получается.

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

praseodim ★★★★★
() автор топика
Последнее исправление: praseodim (всего исправлений: 1)
Ответ на: комментарий от max_lapshin

Но кстати, я кажется начинаю понимать почему стали так популярны микросервисы. Не только для разделения труда разработчиков, но походу и для того,чтобы зоопарк версий и окружений во что-то цельное совместить. На каждую библиотеку/программу свое окружение, его в докер, докеры развернуть и пусть они json-aми обмениваются между собой.

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

Т.е., если нужна более старая версия Python вообще.

в чем опять проблема? Даже очень старые версии питона доступны для установки. conda и poetry решают проблему зоопарка версий питона изкоробки

Так и не доходит о чем я? Я не про опыт как заставить что-то работать, а про опыт, что вообще зачем так любят менять API?

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

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

без совсем острой нужды не ломать совместимость в API, это так дорого?

конечно.

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

Перехать с тредов на libevent означает не «не ломать старое апи», а «написать рядом в два раза больше кода, иммитирующего старое поведение»

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

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

это уже боль сверху тех, кто всё это запускает в прод, да, всё так.

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

Мало конечно, если код уже широко распространился.

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

Для пример как надо проектировать и поддерживать

До-до-до, винда где до сих пор utf8 нормально не поддерживается.

anonymous
()