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)
Ответ на: комментарий от praseodim

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

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

из каких долгосрочных архитектурно-стратосферных целей

Никакие это не стратосферные цели. Numpy написан на си. А сишников мёдом не корми, а дай задефайнить int в INT, int в BOOL и т.д. Просто спроецировали на петон сишный цирк, в котором типы не имеют фиксированного размера, что заставляет в каждой программе вводить алиасы.

ox55ff ★★★★★
()

Пардон, но вот именно это такая мелочь, что бывают и более серьезные проблемы. Вот я недавно хотел скрипт, написанный китайцами (и, кстати, относительно недавно, года 4 назад), проводящий какие-то махинации с хешсуммами, переписать с 2 на 3, чтобы убрать у ПО зависимость от python2 (т.к. 3й уже использовался).

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

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

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

Врёти! В Windows 11 можно включить UTF-8 вместо однобайтовых кодировок. Экспериментально, правда 🤣 Остаётся лишь догадываться, как там всё хорошо спроектировано.

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

Как по мне, софт должен либо обновляться, либо использовать своибиблиотеки со стабильным интерфейсом

Согласен с вами. Интересно, а никто еще не додумался до идеи засунуть в один бинарник программу на питоне(в виде байткода),сам интерпретатор питона и все нужные питоньи модули? Как пример: TurboBasic и Clipper во времена DOS в начале 90х именно так и делали. А что бинарник получится большим - так при нынешних размерах дисков это не критично.

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

но лучше бы не додумывались

А какие принципиальные недостатки у вышеупомянутой идеи? Дефекты какой-то конкретно реализации из рассмотрения исключим.

В достоинствах - явно просматривается бОльшая независимость программы от окружения и переносимость. Если,условно говоря,в динамических зависмостях останутся только самые базовые системные библиотеки уровня libc и около - вероятность незапуска на другой версии или даже другом дистрибутиве линукса можно оценивать как достаточно малую. Ну если только там будет что-то вроде libc5 вместо libc6. Или сильно урезанная libc типа тех что на всяких одноплатных компах встречаются.

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

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

А какие принципиальные недостатки у вышеупомянутой идеи?

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

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

тут вопрос в том, что мы хотим на выходе получить.

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

Вот это главный недостаток идеи - эта идея открывает широкий простор для применения технологий там, для чего они не подходят и не предназначены

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

бабушка запустить программу из исходного кода не способна в принципе

Бабушка может даже и уметь запустить программу из исходного кода - сам видел даму-программиста, у которой есть внук,то есть формально она бабушка:) Но бабушка может не иметь лишнего времени чтобы выполнять все необходимые ритуалы для сборки программы из исходника. Или для разбирательств с версиями всех зависимостей. Вон даже Gentoo сдалось под влиянием сильно выросших затрат времени на компиляцию всего и стало предоставлять бинарные пакеты. Возможность сборки из исходников - это хорошая и полезная возможность,но только тогда,когда она используется по назначению,например в целях модификации и адаптации под решаемую задачу. А не как обязательный и весьма времязатратный ритуал перед запуском вообще чего угодно. Поэтому в стремлении «сделать exe» лично я вижу больше пользы чем вреда. Лучше будет если разработчик один раз озаботится поиском нужных его программе зависимостей и их включением в бинарник,чем это придется делать всем его пользователям самостоятельно. Особенно,как правильно сказано в начале этой темы,учитывая что разработчик может утратить интерес или возможность для поддержки своей программы и ее переделке под очередные версии библиотек. Взять тот же ранее упомянутый мной DOS. Собранные в нем программы периодически используются для всяких достаточно узкоспециальных целей даже сейчас,через три десятка лет. А попробуйте найти например библиотеку от Microsoft C 5.10, которым я тогда софт собирал? А еще надо знать что от версии 6.0 она отличается и могут быть проблемы с работой строковых функций с русским языком. Вот и с Линуксом мы постепенно получаем те же проблемы по мере течения времени и накопления кодовой базы. Общий объем работы по поддержанию актуальности ее зависимостей от разных версий разных библиотек будет только расти с годами и мы в нём утонем.

watchcat382
()

Классическая история. Просто некоторые разработчики даже с многолетним опытом не понимают что значат слова «legacy» и «deprecated» и не понимая значений этих слов ещё их путают. И это настолько смешно что даже грустно иногда.

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

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

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

давайте не будем пользоваться мышками, а как раньше всё на клавиатуре.

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

Вот эти две «особенности» в многих современных программах реально бесят:(

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

watchcat382
()

Я видел ещё хуже библиотеку, называется pandas. Эти датафреймы больной человек придумывал, я уверен. В общем, мой маленький скриптов сломался после обновления. Питонисты должны страдать. Слава Ритчи, Кернигану, Страуструпу и Пайку!

realbarmaley ★★
()