Numpy: Пожелание: использовать семантическое управление версиями

Можно ли считать, что numpy использует семантическое управление версиями, но с начальным 1 ?

Обратите внимание, что почти каждый основной научный проект Python делает то, что делает NumPy: удаляет устаревший код после нескольких выпусков, если это не очень мешает, и увеличивает номер основной версии только для основных вещей.

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

Последнее: NumPy должен быть примерно 14-й версии. Но я предлагаю принять это соглашение только для будущих выпусков.

Кстати: предшественник NumPy, Numeric, действительно использовал семантическое управление версиями и добрался до версии 24 примерно за десять лет. Я не знаю, почему это было изменено при переходе на NumPy.

Мне кажется, что подавляющее большинство проектов Python не используют семантическое управление версиями. Например, сам Python не использует семантическое управление версиями. (Я также не знаю каких-либо основных операционных систем или компиляторов, которые используют semver - вы что-то имеете в виду?) Я согласен с тем, что сторонники semver проделали большую работу по его маркетингу, заставляя многих разработчиков думать, что это хороший идея, но AFAICT по существу не работает в реальном мире для любого проекта, большего, чем left-pad, и я категорически оспариваю идею о том, что люди semver теперь "владеют" традиционным форматом MAJOR.MINOR.MICRO, и все остальные должны переключиться на что-то еще.

Можете ли вы привести пример того, что вы подразумеваете под «схемой маркировки выпуска, которую нельзя ошибочно принять за семантическое управление версиями»? Использовать имена вместо чисел? Вы цитируете управление версиями на основе даты, но наиболее распространенная схема, которую я видел, - это та, которая используется, например, Twisted и PyOpenSSL, которые в настоящее время находятся на 17.9.0 и 17.5.0 соответственно. Мне они кажутся вполне правдоподобными семверскими версиями ...

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

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

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

Неофициальный запрос, который привел меня к выводу, что семантическое управление версиями используется по умолчанию, состоял из разговоров с администраторами установок для научных вычислений. Я также предполагал
более эмпирический подход (перечисление пакетов в последней установке Debian и выбор нескольких из них случайным образом для изучения их подхода к управлению версиями), но это оказалось очень трудным, потому что в немногих проектах четко указано, используют ли они семантическое управление версиями или нет.

Комментарий одного системного администратора особенно поразил меня своей актуальностью: он сказал, что для принятия решения о том, какую версию установить, любые соглашения, кроме семантического управления версиями, бесполезны. Системные администраторы не могут ни подробно изучить каждый пакет (им не хватает времени и компетенции), ни проконсультироваться со всеми своими пользователями (их слишком много). Они должны принять единую политику, которая обычно основана на предположении семантического управления версиями. Например, администратор вычислительного кластера сказал мне, что он проверяет несколько «опытных пользователей», которых он знает лично, прежде чем применить обновление с изменением основного номера версии.

Что касается примеров людей, которые действительно были сбиты с толку, особенно в отношении научных пользователей Python, у меня их много: коллеги по работе, люди, которых я встречаю на конференциях, люди, которые спрашивают совета по электронной почте, студенты моих классов. Обычно это начинается со слов «Я знаю, что вы эксперт по Python, можете ли вы мне помочь с проблемой?» Эта проблема оказывается скриптом, который работает на одном компьютере, но не работает на другом. Большинство из этих людей вообще не рассматривают проблемы зависимости, но некоторые действительно сравнивали номера версий двух установок, обнаруживая лишь «небольшие различия».

Как отметили @ eric-wieser и @rgommers , мой запрос почти синонимичен запросу начального "1". быть удаленным из версий NumPy. Другими словами, NumPy де-факто уже использует семантическое управление версиями, даже если оно не является результатом политического решения и поэтому, вероятно, не выполняется строго. Тем не менее, это предполагает, что NumPy может принять семантическое управление версиями почти без изменений в текущем рабочем процессе разработки.

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

К сожалению, семантическое управление версиями также бесполезно для этого :-(. Я не хочу расщеплять волосы или преувеличивать; я полностью понимаю, что это настоящая проблема. Но только потому, что проблема реальна, не означает, что у нее есть решение. Вы принципиально не можете свести вопрос «следует ли мне обновить это программное обеспечение?» К простой механической проверке. Это фантастика. Проекты, использующие semver, регулярно выпускают основные выпуски, на которые все их пользователи должны немедленно обновляться, и регулярно вносить критические изменения в незначительные выпускает.

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

Хотя мне нравится эта часть :-). Я сомневаюсь, что мы согласимся с философией semver, но гораздо проще обсудить конкретные эффекты различных схем управления версиями и какой результат мы считаем наиболее желательным.

Я не думаю, что концепция semver имеет какое-то отношение к этой политике - действительно ли системный администратор, с которым вы разговаривали, проверяет каждый проект, чтобы узнать, используют ли они semver? Как вы сказали, в большинстве проектов нет, трудно даже сказать, какие из них работают. И это та же политика, которую системные администраторы использовали задолго до того, как появился semver. Я думаю, что лучше охарактеризовать эту политику было бы: «следуйте рекомендациям проекта о том, насколько осторожно следует быть при обновлении», наряду с древней традицией, согласно которой основные выпуски являются «большими», а второстепенные - «маленькими».

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

@njsmith Хорошо, давайте

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

Учитывая, что NumPy не имеет последствий для безопасности, я не понимаю, как и почему проект NumPy должен давать универсальные рекомендации. У людей и учреждений разные потребности. Вот почему у нас есть и ArchLinux, и CentOS с очень разными политиками обновления.

@khinsen Пакет oldnumeric прежнему отлично работает, и его можно установить с помощью:

pip install oldnumeric

Возможно, это может быть ваш предлагаемый «стабильный numpy», где интерфейс для numpy ограничен Python / Cython, и ничего не меняется. Конечно, писать код с помощью oldnumeric очень сложно, но нельзя использовать оба варианта.

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

Вопрос: Как системный администратор (даже только на своем персональном компьютере), ожидаете ли вы, что пакет упадет полный уровень API с версии 1.8 до версии 1.9?

Для тех, кто ответил «да», второй вопрос: можете ли вы назвать какое-либо программное обеспечение, кроме numpy, которое когда-либо делало это?

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

Но падение oldnumeric было не худшим событием в недавней истории NumPy. Эта честь принадлежит изменению семантики копирования / просмотра некоторых операций, таких как diagonal . Код, который возвращает разные результаты в зависимости от версии NumPy (изменение второстепенного номера версии!), - настоящий кошмар.

Кстати, поскольку мало кто знает эту историю: pip install oldnumeric работает два дня назад, потому что @xoviat подготовил этот дополнительный пакет и поместил его в PyPI. Большое спасибо!

Ожидаете ли вы, что из пакета будет удален полный уровень API с версии 1.8 до версии 1.9?

К какому слою вы имеете в виду?

Вы можете назвать какое-либо программное обеспечение, кроме numpy, которое когда-либо делало это?

SciPy сбросил пакеты weave и maxentropy , pandas регулярно ломает основные функции. Я уверен, что есть еще много ярких примеров. EDIT: сам Python, например, см. Https://docs.python.org/3/whatsnew/3.6.html#removed

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

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

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

К какому слою вы имеете в виду?

поддержка numeric / numarray, я полагаю

@rgommers Извините, я должен был сказать «еще один пример вне экосистемы SciPy».

Кроме того, я не жалуюсь на отказ от поддержки oldnumeric . Я жалуюсь на то, что сделал это без изменения основного номера версии.

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

Не забывайте, что экосистема SciPy имеет огромное количество низкопрофильных пользователей, которые не следят активно за развитием событий. Python и NumPy - это элементы инфраструктуры той же природы, что и ls и gcc для них. И часто это не так: они используют какое-то программное обеспечение, которое написано на Python и просто зависит от NumPy, а когда оно ломается, они полностью теряются.

@rgommers Извините, я должен был сказать «еще один пример вне экосистемы SciPy».

Только что отредактировал свой ответ со ссылкой на примечания к выпуску Python, находящиеся за пределами экосистемы SciPy.

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

Этого просто не будет. Если вместо 1.12, 1.13, 1.14 и т.д. у нас будет 12.0, 13.0, 14.0, то пользователи привыкнут к этому и будут использовать ту же стратегию обновления, что и раньше. Подавляющее большинство не станет вдруг более консервативным.

Не забывайте, что экосистема SciPy имеет огромное количество низкопрофильных пользователей, которые не следят активно за развитием событий. Python и NumPy - это элементы инфраструктуры того же характера, что и ls и gcc для них. И часто это не так: они используют какое-то программное обеспечение, которое написано на Python и просто зависит от NumPy, а когда оно ломается, они полностью теряются.

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

Другие минусы изменения схемы управления версиями сейчас:

• мы будем вносить изменения в управление версиями без изменения политики обслуживания, это скорее запутает, чем поможет
• Теперь мы в основном следуем примеру Python и делаем то же самое, что и вся остальная экосистема. Это хорошая вещь
• возможно, самое главное: мы потеряем способность сигнализировать о действительно серьезных изменениях. того типа, для которого мы собираемся перейти на 2.x, например, выпуск, который нарушит ABI.

Мой базовый ориентир - это не Python, а типичная установка программного обеспечения. Как я уже сказал, для многих (возможно, большинства) пользователей NumPy - это инфраструктура вроде gnu-coreutils или gcc. Они не интерпретируют номера версий специально в контексте экосистемы SciPy.

Я быстро проверил систему Debian 9 с примерно 300 установленными пакетами. 85% из них имеют номер версии, начинающийся с целого числа, за которым следует точка. Наиболее распространенные целочисленные префиксы: 1 (30%), 2 (26%), 0 (14%) и 3 (13%). Если бы NumPy принял схему нумерации версий, соответствующую общим ожиданиям (то есть семантическое управление версиями или близкое приближение), это определенно выделилось бы и к нему относились с осторожностью.

Также обратите внимание, что единственные обновления в установленном Debian программном обеспечении, которые когда-либо ломали меня, были в экосистеме SciPy, за исключением обновления Emacs, которое внесло изменения в org-mode, которые нарушили самодельное расширение org-mode. Таким образом, общие префиксы с низким номером версии действительно указывают на то, что наиболее широко используемое программное обеспечение намного более стабильно, чем NumPy и его друзья.

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

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

Согласно этим стандартам NumPy даже не следует примеру Python, потому что единственные изменения в семантике, о которых я знаю, в языке Python произошли от 2 до 3.

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

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

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

Я все еще не согласен. Даже на Debian, который определенно не является «типичной установкой программного обеспечения» для нашей пользовательской базы (это было бы что-то вроде Anaconda в Windows). Вы также, кажется, игнорируете мой аргумент выше, что пользователь даже не может нормально видеть номер версии (ни с pip install --upgrade ни с диспетчером пакетов).

Кроме того, ваш опыт, что все остальное никогда не ломается, вероятно, связано с тем, что вы используете такие вещи, как утилиты ОС и программы с графическим интерфейсом, а не другие большие цепочки зависимостей. Например, вся экосистема JavaScript / NodeJS, вероятно, более хрупкая, чем экосистема Python.

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

Это хороший пример тонкостей здесь. Насколько мне известно, MMTK и другие ваши проекты - единственные сохранившиеся проекты, на которые повлияло удаление кода совместимости numeric / numarray. Сколько пользователей, по вашему мнению, у вас есть? 100? 1000? У NumPy миллионы, так что, возможно, это удаление затронуло 0,1% наших пользователей? Это определенно не ноль, и тот факт, что он маленький, не означает, что это не имеет значения - я бы хотел, чтобы мы могли поддерживать 100% пользователей навсегда во всех отношениях. И я понимаю, что вам особенно больно получать 100% жалоб от ваших пользователей.

Но если мы увеличим для этого наш основной номер версии, это будет означать, что для 99,9% наших пользователей мы только что кричали волк. Это ложное срабатывание. OTOH для этих 0,1% пользователей был действительно важен. Тем не менее, нередко, несмотря на все наши усилия, мы нарушаем более 0,1% пользователей на микрореллах . Так что же нам делать?

Эти нюансы просто невозможно передать через тупой инструмент номера версии. Всем нужен быстрый способ узнать, нарушит ли обновление их код, и по уважительным причинам. Semver популярен, потому что обещает это сделать. Это популярно по той же причине, по которой принято считать, что модные диеты могут вылечить рак. Желаю, чтобы Семвер тоже выполнил свои обещания. Но это не так, и если мы хотим быть хорошими инженерами, нам нужно иметь дело со сложностями этой реальности.

Я не понимаю, как и почему проект NumPy должен давать универсальные рекомендации. У людей и учреждений разные потребности.

Мы даем универсальные рекомендации, потому что у нас есть только 1 номер версии, поэтому по определению все, что мы с ним делаем, является универсальной рекомендацией. Мы не можем это контролировать.

Эта честь принадлежит изменению семантики копирования / просмотра некоторых операций, таких как diagonal .

IIRC, мы буквально не получили ни одной жалобы на это от кого-то, кто сказал бы, что это нарушило их код. (Может быть, один человек?) Я не говорю, что это означает, что никто не пострадал, очевидно, что люди, которые жалуются на изменение, как правило, лишь небольшая часть тех, кого это коснулось, но если вы используете жалобы в качестве приблизительного доказательства для реального мировое влияние, то я не думаю, что это входит в число 50 лучших.

И, кстати, я почти уверен, что если вы исследуете глубокую историю, вы найдете гораздо более вопиющие изменения, чем это :-).

Также обратите внимание, что единственные обновления в установленном Debian программном обеспечении, которые когда-либо ломали меня, были в экосистеме SciPy, за исключением обновления Emacs, которое внесло изменения в org-mode, которые нарушили самодельное расширение org-mode.

С уважением, я думаю, что это больше говорит о том, как вы используете NumPy против Debian, чем о NumPy против Debian. Я люблю Debian, я использую его почти 20 лет, и я не могу сосчитать, сколько раз он ломал вещи. Буквально на прошлой неделе какая-то странная проблема с новым gnome нарушила мои сценарии входа в систему, а какое-то другое обновление сломало мою точку отслеживания . (Оба исправлены сейчас, но все еще.) Я также отмечу, что emacs Debian был настроен на загрузку и запуск кода по незашифрованным / незащищенным каналам в течение многих лет из-за проблем с обратной совместимостью при включении проверок безопасности. Я не думаю, что есть такая вещь, как выпуск gcc, который не сломает некоторых людей, хотя бы потому, что люди делают такие вещи, как использование -Werror а затем незначительные изменения в поведении предупреждений (которые могут полагаться на тонкие взаимодействия между проходами оптимизации и т. д.) становятся критическими изменениями.

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

Общие префиксы с низким номером версии обусловлены тем, что наиболее широко используемое программное обеспечение не использует semver.

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

Да, поэтому мы крайне осторожно относимся к таким изменениям.

Здесь есть некоторое несоответствие во взглядах: вы, кажется, думаете, что мы все время волей-неволей меняем вещи, не заботимся об обратной совместимости и т. Д. Я могу это уважать; Я так понимаю, это отражает ваш опыт. Но наш опыт показывает, что мы очень внимательно относимся к таким изменениям, и я бы сказал, что когда я разговариваю с пользователями, ~ 5% имеют вашу точку зрения и ~ 95% считают, что numpy либо хорошо справляется со стабильностью, либо или что он слишком хорошо выполняет свою работу и должен с большей готовностью ломать вещи. Возможно, вас утешит то, что, даже если мы вас разочаруем, мы разочаруем и эту последнюю группу :-).

за исключением обновления Emacs

Что ж, если не по теме, это действительно пример другой стороны стабильности. Emacs был статичным в течение многих лет из-за сопротивления Столлмана изменениям, и это привело к форку xEmacs. Мой собственный путь пошел Emacs -> xEmacs, черт возьми, -> Vim;) Преждевременная окаменелость также является причиной того, что я перестал использовать Debian в то время. Для некоторых вещей изменения просто не нужны или даже не нужны, и я ожидаю, что есть люди, использующие древние версии BSD на старом оборудовании, спрятанном в шкафу. Но не думаю, что таких мест много.

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

Я пытаюсь обновить проекты на
https://github.com/ScientificPython. Это требует обновления кода Python, который
использовал старый C API (я имею в виду старый; некоторые функции, такие как Py_PROTO, были
с 2000 г.). PR приветствуются, но я не уверен, что кто-нибудь
хочет тратить на это свое время.

Я думаю, что более серьезная проблема, которую он поднял, заключается в том, что существует "много
проекты »(не знаю, где именно они находятся, потому что все проекты
что я видел поддержку Python 3), которые также нуждаются в обновлении; как это
определили, на какие проекты выделяется время разработчика NumPy? А также я
не думайте, что его основное утверждение было неверным: SciPy значительно выигрывает от
тот факт, что он мог просто копировать и вставлять старые проекты fortran (например,
fftpack) с небольшими изменениями или без них. Если бы они были написаны, скажем,
"fortran 2" и новые компиляторы скомпилировали только "fortan 3",
были значительные проблемы.

Тем не менее, эти проблемы на самом деле не являются ошибкой NumPy. Несмотря на то, что у него есть
сказал, что с установленным NumPy 1.13 oldnumeric по-прежнему прошел все тесты,
указание, что NumPy здесь не виноват. Поскольку старый числовой API
буквально более десяти лет назад (может быть, приближается к двум десятилетиям!), и все еще
работает на последнем NumPy, я думаю, что NumPy API, вероятно, стабильный
довольно.

@charris Я полностью согласен с вами в том, что «никогда ничего не менять» -

Я хочу сказать, что экосистема SciPy стала настолько популярной, что ни один подход к управлению изменениями не подходит всем. Это зависит от того, насколько быстро будут развиваться методы и их реализация в данной области, от технических компетенций практиков, от другого программного обеспечения, от которого они зависят, от ресурсов, которые они могут инвестировать в код и т. Д.

Текущая основная команда NumPy больше заботится о прогрессе (в направлении, которое имеет значение для некоторых областей, но в значительной степени не имеет отношения к другим), чем о стабильности. Это нормально - в мире открытого исходного кода люди, которые делают работу, решают, над чем они хотят работать. Однако у меня сложилось впечатление, что они не понимают, что многие люди, чья работа зависит от NumPy, имеют другие потребности, чувствуют себя брошенными командой разработчиков и начинают отходить от SciPy к более традиционным и стабильным технологиям, таким как C и Fortran ( и, в одном случае я знаю, даже в Matlab).

Я понятия не имею, какой процент пользователей NumPy достаточно недоволен текущим положением дел, и не думаю, что кто-то еще. Когда программный пакет становится инфраструктурой, вы не сможете легко оценить, кто от него зависит. Многие из тех, кто это знает, даже не знают об этом, а большая часть кода, который зависит от NumPy (прямо или косвенно), не является общедоступным и / или его трудно обнаружить.

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

Наконец, некоторые из вас, кажется, считают, что я веду личную битву из-за моего собственного кода. Возможно, вас удивит, что мое личное отношение не то, что я защищаю здесь. Моя собственная точка зрения на скорость изменений находится где-то посередине между тем, что является обычным в моей области, и тем, что, по моему мнению, преобладает в команде NumPy. В большей части моей работы сегодня используются Python 3 и NumPy> 1.10. ММТК 20 лет, и сегодня я много делаю по-другому. Довольно часто я беру фрагменты кода из MMTK, которые мне нужны для конкретного проекта, и адаптирую их к «современному SciPy», но это то, что я могу сделать с уверенностью только потому, что написал исходный код.

Я поддерживаю стабильный MMTK как услугу для сообщества, а не для собственного использования, что объясняет, почему я выполнял обслуживание минималистично, избегая крупномасштабных изменений в кодовой базе. Очень трудно найти как финансирование для программного обеспечения, так и компетентных в предметной области разработчиков, поэтому MMTK всегда оставался проектом, в котором участвовал один сопровождающий плюс случайные участники. Я даже не уверен, что перенос всего MMTK на «современный SciPy» принесет кому-либо пользу, потому что большая часть кода, который зависит от MMTK, полностью не поддерживается. Но тогда это верно для большей части кода Python, который я вижу вокруг себя, даже кода, совершенно не связанного с MMTK. Это реальность области исследований, в которой в центре внимания находятся эксперименты, а не вычисления и кодирование.

@xoviat Количество тестов в oldnumeric невероятно мало. Я бы не сделал много выводов из того факта, что они проходят с NumPy 1.13.

Модулям расширения C, которые вы просматривали, буквально 20 лет, и они были написаны для Python 1.4. В то время это был один из самых сложных примеров комбинаций Python-C и фактически сформировал раннюю разработку Numeric (до NumPy) и даже самого CPython: объекты CO (pre-Capsules) были введены на основе потребностей ScientificPython и MMTK. .

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

@rgommers Я не игнорирую ваш аргумент о том, что пользователь даже не видит номер версии. Это просто неверно для окружающей среды, которую люди используют повсюду. Люди, которые принимают решение об обновлениях (не всегда конечные пользователи), видят это. Они не просто выполняют команду «pip install --upgrade» раз в неделю. Они даже сочли бы это небрежным отношением.

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

И да, NodeJS хуже, согласен. К счастью, я легко могу это игнорировать.

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

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

Все дело в контроле над своими инструментами.

Обещаю, я никогда не ворвусь в лабораторию твоего коллеги посреди ночи и не обновлю их. У меня даже нет балаклавы .

Люди, которые принимают решение об обновлениях (не всегда конечные пользователи), видят это. Они не просто выполняют команду «pip install --upgrade» раз в неделю. Они даже сочли бы это небрежным отношением.

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

Текущая основная команда NumPy больше заботится о прогрессе (в направлении, которое имеет значение для некоторых областей, но в значительной степени не имеет отношения к другим), чем о стабильности.

Мне очень жаль, но это просто показывает, что вы вообще не следили за разработкой NumPy в последние несколько лет или у вас есть особый набор очков. На самом деле NumPy - очень сложный проект, потому что есть много опасений по поводу обратной совместимости. Это одна из основных причин, по которой нам трудно привлекать новых сопровождающих.

и, в одном случае я знаю, даже в Matlab

Matlab был известен нарушением совместимости. Первое, что сделали совместные проекты, использующие Matlab, - это указание версии, которую должны были использовать все, то же самое и с Microsoft Word, если он использовался для документации. Я знаю людей, которые перешли на NumPy именно для улучшения совместимости. У Matlab есть свои достоинства, но совместимость к ним не относится. Может, все изменилось?

Однако я думаю, что в будущем мы можем сделать несколько вещей, которые могут помочь с совместимостью. Первый связан с текущим обсуждением нэпа. Теперь, когда NumPy стал более зрелым, может быть хорошей идеей больше использовать NEP, когда предлагаются изменения, влияющие на совместимость, особенно если NEP более общедоступны и доступны для поиска. Во-вторых, мы могли бы попытаться установить колеса для старых версий NumPy на PyPI, если это не слишком много работы. Использование виртуальных сред кажется лучшей текущей идеей для получения воспроизводимости, и более широкий выбор колес для загрузки может помочь в этом.

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

Благодаря усилиям @ matthew-brett, похоже, что текущий статус таков: колеса Windows вернулись к 1.10 , MacOS вернулись к 1.5 (за исключением отсутствия 1.7 ), а Linux вернулись к 1.6 .

Ситуация с MacOS / Linux кажется вполне разумной. Я думаю, мы могли бы залить больше выпусков Windows? OTOH pip install в Windows никогда не работал без героических усилий, поэтому я не уверен, что у этого есть большая аудитория. У нас уже есть 2 года, и со временем он будет расти.

Кроме того, когда мы в последний раз загружали старые колеса, кто-то рассердился на нас, потому что их рабочий процесс предполагал, что колес не было, и это нарушало обратную совместимость для них :-)

Хотел бы услышать эту историю.

Не то чтобы я действительно хорошо разбирался в этом, но я думаю, что мы можем попытаться улучшить ситуацию (хотя я не совсем уверен, что это значит!). Дело в том, что нам нужно двигаться вперед медленно, и, за исключением, возможно, некоторых ошибок, все выпуски были предназначен для взлома кода очень немногих людей. Я думаю, что наш второстепенный выпуск означает, что «почти все люди должны обновляться и иметь возможность обновляться, ничего не замечая», и я искренне верю, что это правда. (Очевидно, что есть вещи, которые повлияли на многих людей, например, отказ от целочисленных значений, но они не приводят к неправильным результатам и долго разрабатывались)

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

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

Что касается gcc и т. Д. Например, я не очень разбираюсь в компиляции / C ++, меня раздражает gcc 4.8 или около того, заставляя меня выяснять, как правильно менять флаги из-за некоторых функций C ++ 11 или так ожидаемо, что вызывает очень похожие реакции на электронные письма, которые вы, кажется, получаете о numpy, поэтому я не уверен, что это сильно отличается :).

В любом случае, я не хочу здесь слишком много обсуждать, я ценю отзывы о том, можем ли мы быть слишком быстрыми или недостаточно осторожными, но я должен признать, что я также не совсем понимаю, что изменение основной версии сильно поможет с тот. Лично я считаю, что 1.13 и 1.6 в некотором смысле представляют собой по крайней мере одну основную версию, но между ними нет ни одной промежуточной версии, на которую я могу указать и сказать: это было серьезным нарушением совместимости для многих пользователей.
Я помню, как читал комментарии в коде: «Давай сделаем это в Numpy 2, может быть», именно из-за боязни любого взлома вообще, с таким подходом, я боюсь, что numpy сильно застопорился бы, и, честно говоря, я немного горжусь тем, что являюсь частью из того, что мне, по крайней мере, казалось снова более активной фазой, которая была необходима, и что было бы трудно, если бы мы были еще более консервативными. (Я, вероятно, предвзято, так как не очень понимаю, что произошло до того, как я пришел :)).

Извините, может, в этом нет смысла (у нас только что была рождественская вечеринка). Предложение semver имеет смысл, но я должен признать, что оно не похоже на настоящее решение. Я могу согласиться с попытками более агрессивно увеличивать основную версию, но я также не согласен с тем, чтобы называть каждый выпуск основным выпуском. Я также могу согласиться с попыткой быть более консервативным в некоторых случаях, но я, честно говоря, не совсем уверен, что это такое (просто посчитайте количество зависших PR, потому что никто не уверен, может ли это где-то нарушить совместимость;), я уверен, что это это хорошая порция)?

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

Итак, после такого долгого лепета:

• «Почти ни один код не сломан» кажется, может быть нормально для минорной версии?
• Нам нужно двигаться вперед медленно?
• В конце концов, что-то сломается, и, возможно, иногда мы сможем увеличить основную версию. Возможно, даже попытайтесь изменить некоторые типы FutureWarning в основных версиях. (Откровенно говоря, не верю, что это поможет, но я хочу попробовать)

Самое главное: я знаю разочарование, но есть ли для нас реальное решение? Как вы думаете, если мы будем агрессивно увеличивать основную версию, вы получите меньше писем?

@xoviat , вы спрашиваете историю про получение жалоб на загрузку колес для старых версий? Это был №7570.

Мое любимое определение semver (я больше не могу найти ссылку на исходное сообщение):

• майор: мы специально взломали код пользователя
• второстепенный: мы случайно взломали код пользователя
• патч: мы устранили пользовательские обходные пути до ошибок последнего незначительного выпуска

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

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

Я думаю, что в этом разговоре не хватает того, что старые версии библиотек всегда доступны (на pypi из источника), поэтому, если у вас есть код, требующий старую версию python / numpy / matplotlib, используйте более старые версии. В пользовательских средах управлять этим не так уж и сложно.

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

@njsmith Довольно забавно. IMO № 7570 не является допустимой проблемой, учитывая, что
NumPy соответствовал спецификации колеса manylinux. Как правило, колеса
следует загрузить для более старых версий при условии, что время свободно. Дано
это время не бесплатно, мы могли бы просто отметить, что люди могут строить колеса
для конкретной версии NumPy, если они этого хотят; представление PR в
репозиторий numpy-wheels. Или нет.

@xoviat Я имею в виду, что если их система сломалась, она сломалась; возможность указать на спецификацию на самом деле этого не меняет. В целом в этих обсуждениях я думаю, что нам следует больше заботиться о фактических последствиях для конечных пользователей, чем о теоретической чистоте. Но в данном случае OTOH, я думаю, был правильным призывом держать колеса в рабочем состоянии, учитывая, что они уже работали над проблемой, колеса уже были загружены, и, насколько мы можем судить, выгоды получили намного больше людей, чем возникли проблемы. Но это интересное напоминание о том, насколько тонкой может быть «обратная несовместимость» и как сложно создать общие правила.

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

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

С другой стороны, я, конечно, признаю, что у меня очень особенный набор очков, но это верно для всех остальных участников этого обсуждения. Мои очки - очки "традиционных научных вычислений", которые являются моей рабочей средой. Базовый план (ожидание по умолчанию) состоит в том, что обновления никогда ничего не ломают намеренно. Это политика стандартизированных языков (C, Fortran), но также и библиотек инфраструктуры (BLAS, LAPACK, MPI, ...). Тем не менее инновации случаются (например, ATLAS). Если вы думаете, что это консервативно, позвольте мне описать, что консервативность означает в моем мире: никогда не устанавливайте версию чего-либо, старше двух лет, чтобы убедиться, что большинство ошибок известно. Это обычная политика для суперкомпьютеров, время которых очень дорого и результаты которых трудно проверить по этой причине.

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

@seberg «Почти ни один код не сломан» теоретически подходит для минорной версии. Но как только часть программного обеспечения приобретает статус инфраструктуры (а, на мой взгляд, NumPy находится на этом уровне), невозможно оценить, сколько разработчиков и пользователей могут быть затронуты. Тогда критерий неизменно становится «почти ни на кого, о ком я могу думать», и это не очень хорошо.

@tacaswell Я думаю, что разница между «намеренно» и «случайно» имеет большое значение на практике. Это влияет на отношение всех к переменам. Просто посмотрите на другие аспекты жизни. Если бы различие не имело значения, мы могли бы исключить слово «осторожный» из английского языка.

Что ж, честно говоря, я думаю, что идея «серьезной перестройки» в значительной степени заброшена прямо сейчас, поскольку для этого потребуется либо гораздо больше возможностей разработки, а затем может возникнуть совершенно другой беспорядок (см. Py2 и py3 в течение первых нескольких лет)?

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

Итак, иногда нам, вероятно, следует признать, что это может быть неправда, но в противном случае я бы предпочел получить решения, чтобы убедиться, что мы больше не ломаемся. Конечно, вы предложили решение (очень-очень консервативное и начав с numpy 2 с капитальным ремонтом), но как только мы признаем, что это решение просто невозможно без значительного финансирования или около того, что еще мы можем сделать?

Или позвольте мне прояснить: если вы знаете кого-то, способного следовать за numpy dev, который может следить за тем, чтобы быть более консервативным, когда это необходимо, вы знаете, я по крайней мере ценю это. Но лично мне не нравится отказываться от нашего прогресса, по крайней мере, медленно избавляться от некоторых темных уголков в numpy, чтобы обеспечить будущее развитие. В лучшем случае мы закончим с мертвым NumPy и заменой через несколько лет, в худшем мы просто закончим тем, что будем опережать и ниже по течению будем разочарованы невозможностью двигаться вперед и, возможно, появятся «замены», которые по своей природе если быть не таким зрелым, только усугубит ситуацию.

Я должен согласиться с @seberg о создании другого пространства имен. В
все предположение, лежащее в основе этой идеи, состоит в том, что проект NumPy имеет неограниченное количество
талант и ресурсы для поддержки библиотеки, подходящей для всех.
Однако это не так. Разработчики не идеальны, поэтому обычно
ошиблись с первого раза. Люди, пишущие исходный числовой код
не могли предсказать все сценарии, в которых он будет использоваться, и они
не мог предсказать рост альтернативных реализаций, таких как PyPy.

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

Таким образом, я полностью понимаю разочарования людей. Но как @njsmith
сказал, что не существует решения проблемы, которое удовлетворило бы каждого пользователя.
Есть только решения, которые большую часть времени удовлетворят большинство пользователей. И
реальность такова, что если NumPy потворствует меньшинству пользователей (не
уничижительным образом), который требовал стабильности API превыше всего,
Финансирование NUMFOCUS может иссякнуть, потому что будет непонятно, на какие деньги
был использован, а где бы мы были? Наверное, в ситуации, когда
MMTK больше не может зависеть от NumPy, как и в случае, когда он мог
больше не зависят от Numeric.

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

Я действительно согласен с вами, но я не понимаю, как это возможно без серьезного финансирования / видения. NumPy представляет собой огромный объем работы. Может быть, @teoliphant и @skrah справятся с этим с плюсом , но это будет тяжелая битва.

Учитывая тот NumPy, который у нас есть сегодня, я думаю, что мы делаем все, что можем.

Для тех, кто ответил «да», второй вопрос: можете ли вы назвать какое-либо программное обеспечение, кроме numpy, которое когда-либо делало это?

django - еще одна примечательная программа, в которой не используется семантическое управление версиями. Они используют основные изменения, чтобы указать на существенные перерывы, но не рекомендуют изменения в .x после длительного периода предупреждений. Более-менее похоже на NumPy.

Я действительно согласен с тобой,

@shoyer из интереса, почему? Как бы это не превратиться в какой-то момент в очень болезненный переход в стиле py3k на новую базу кода?

Это политика стандартизированных языков (C, Fortran), но также и библиотек инфраструктуры (BLAS, LAPACK, MPI, ...). Тем не менее инновации случаются (например, ATLAS).

Инновации в темпе LAPACK / ATLAS / OpenBLAS - это рецепт того, что NumPy станет неактуальным намного быстрее, чем в противном случае.

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

Как бы это не превратиться в какой-то момент в очень болезненный переход в стиле py3k на новую базу кода?

Большая разница в том, что, хотя Python 3 является переключателем все / ничего (для программ Python), легко или, по крайней мере, выполнимо смешивать / сопоставлять разные библиотеки ndarray. Интерфейс буфера означает, что вы можете передавать данные туда и обратно без копий. Если вы принуждаете входные данные к своим функциям с помощью np.asarray() вы можете даже не заметить, если какая-то библиотека, с которой вы работаете, переключает на возврат массивов другого типа.

Это похоже на повторяющиеся части numeric / numarray / numpy
опыт, который тоже был не очень приятным (интерфейс буфера будет
помощь, но я думаю, что такой переход все равно будет включать ручной код
изменения, не все из которых тривиальны). Тоже не получится
для библиотек, таких как Scipy, для «обновления» до «нового массива» без
нарушение обратной совместимости, поэтому проблема просто всплывает вверх
экосистема, вынуждая другие библиотеки принять аналогичное решение
отказаться от старых пространств имен.

Если бы все принудительно вводили свои данные с помощью np.asarray , то np.matrix не было бы проблемой :-).

Если разные библиотеки массивов могут договориться о типах утки, и мы ограничимся dtypes, представляемыми протоколом буфера, тогда это может работать. Но если весь смысл перезаписи будет заключаться в внесении несовместимых изменений интерфейса в объекты массива и реализации новых типов dtypes ... Я действительно не понимаю, как заставить его работать. Конкретный пример: одна очевидная вещь, которую нужно исправить при таком переписывании, - это поведение ndarray.dot на входах большой размерности. Но если есть библиотека, которая выполняет def f(a, b): a.dot(b) , то создание такой библиотеки потенциально сломает ее. На самом деле не имеет значения, называется эта библиотека numpy или нет.

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

@rgommers Пожалуйста, прочтите еще раз то, что я написал: я не, повторяю, нет , предлагаю NumPy перенять темп LAPACK. Я предлагаю, чтобы это ясно сигнализировало людям, которые имеют такие ожидания (т.е. 80% людей в моем окружении), что это не так.

@njsmith Я ориентированного проектирования . Это не лучший подход к структурированию кода для единой структуры данных с множеством функций, которые работают с ней. Напишите np.dot(a, b) и описанная вами проблема мгновенно исчезнет. Вы можете иметь любое количество реализаций namespace.dot вам нравится. Каждая библиотека может использовать ту, которая ей нравится, и они все еще могут взаимодействовать. ОО создает единое пространство имен для методов, и это проблема.

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

Просто чтобы показать, что я могу сломать вещи ;-)

@rgommers Пожалуйста, прочтите еще раз то, что я написал: я не, повторяю, нет, предлагаю NumPy перенять темп LAPACK.

Я это понимаю. Два абзаца моего ответа не связаны напрямую, извините, если это сбивает с толку.

Я предлагаю, чтобы это ясно сигнализировало людям, которые имеют такие ожидания (т.е. 80% людей в моем окружении), что это не так.

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

@khinsen Хорошо, тогда представьте, что мой пример - это несовместимые изменения в индексировании, которые мы бы обязательно сделали, если бы это было возможно. (У причудливой индексации есть несколько чрезвычайно запутанных угловых случаев.)

@njsmith В некотором смысле

Боковое замечание: на мой взгляд, причудливая индексация - самая большая ошибка дизайна в NumPy, потому что у нее даже нет (и никогда не было) однозначной спецификации. Он выполняет np.take для целочисленных аргументов и np.repeat для логических аргументов. Поскольку логические значения в Python являются подтипом целых чисел, это создает неоднозначность для аргументов, содержащих только нули и единицы.

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

Я обсуждаю причудливое индексирование в своих курсах SciPy исключительно для того, чтобы сказать людям, чтобы они не использовали его. Есть np.take и np.repeat которые работают отлично и не вызывают никаких проблем. И если вы используете их как функции, а не как методы, проблем с объектно-ориентированным программированием тоже нет. Для тех, кому не нравится np.repeat потому что имя не предполагает намерения при использовании с логическими значениями, просто введите псевдоним: select = np.repeat . Опять что-то излишне затрудненное ОО.

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

С моей точки зрения, самый сложный вопрос - это арифметика. Вы действительно хотите написать a+b для добавления массива, а не np.add(a, b) , но нет универсального соглашения о том, что именно должен делать a+b , в частности, с точки зрения результата dtype . Это была одна из основных проблем разделения Numeric / numarray, которая привела к введению новых скалярных типов в NumPy, которые также вызывают у них немало неприятных сюрпризов. Я считаю, что эту проблему можно решить, но не в дополнительных комментариях к обсуждению проблемы на GitHub.

@rgommers Если бы «запрос закрепленной версии для этих 80%» был возможен, я бы сделал это давно. «Эти 80%» - это не организованное сообщество, с которым можно поговорить. Это большое количество людей, которые разделяют общую культуру, но не взаимодействуют друг с другом. Ваше предложение немного похоже на «попросить пользователей Windows перейти на Linux» (или наоборот).

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

Я не хочу слишком сильно мешать этому, но я понятия не имею, о чем вы говорите с массивами np.repeat и bool

@ eric-wieser повторите 0 раз, и вы удалите его из массива, 1 раз, и он останется. Я не согласен с обучением этому вместо индексации, но что бы то ни было (худшая странность в наши дни ушла, так что да, в numpy a bool не является int в большинстве случаев, принимая это, теперь у вас все в порядке, я думаю, так что это даже несовместимость с списки, если вы хотите видеть это таким, но ...).

Боковой момент, так как это уже никуда не денется :). Я на самом деле отчасти надеюсь, что постепенное исправление вещей в numpy упростит в какой-то момент в будущем сделать numpy более заменяемым.

Ваше предложение немного похоже на «попросить пользователей Windows перейти на Linux» (или наоборот).

Хм, просить технически компетентных (я надеюсь ...) людей узнать, как на самом деле работают номера версий в реальном мире, на

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

И, предположительно, если мы сделаем этот переход, вы перейдете на SciPy, потому что это следующая часть инфраструктуры? Когда это перестает быть инфраструктурой? И почему NumPy и другие части инфраструктуры хотят иметь схему управления версиями, совершенно отличную от самой Python и всей остальной научной экосистемы Python?

Эти 80% - не организованное сообщество, с которым можно поговорить.

Администраторы суперкомпьютеров, которые вы используете, действительно должны разговаривать друг с другом, верно? Не может быть массы людей, которые бегают вокруг обновлений программного обеспечения на этой паре систем и никогда не разговаривают. Я не имел в виду, что вы должны обучать 80% всех системных администраторов во всем мире, только тех, кто вам нужен.

@seberg Заявление о том, что списки и массивы представляют собой разные типы данных, которые используют только индексирование как общее свойство, является допустимой точкой зрения. Это также упростило бы объяснение существования определенных скаляров NumPy. Но я не видел ни одной презентации NumPy, которая придерживалась бы этой точки зрения.

@rgommers

Администраторы суперкомпьютеров, которые вы используете, действительно должны разговаривать друг с другом, верно?

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

Я не имел в виду, что вы должны обучать 80% всех системных администраторов во всем мире, только тех, кто вам нужен.

Это не обо мне - у меня есть решение, которое отлично работает для меня: я всегда устанавливаю Python и все библиотеки из исходного кода в свой домашний каталог.

Речь идет о людях, с которыми я сотрудничаю, и о людях, которые просят меня о помощи (например, потому что они в прошлом участвовали в одном из моих курсов Python). У них нет технической компетенции для управления своей собственной установкой Python и передачи их кому-то другому (администратору или более опытному коллеге).

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

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

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

Это потому, что они используют ограниченное количество библиотек, в основном медленных, таких как LAPACK & co. Как отметил @njsmith , у большинства программ низкие номера версий, поскольку они не используют семантическое управление версиями.

@rgommers Они действительно используют в основном медленные библиотеки, хотя я бы не сказал "небольшое количество".

Как отметил @njsmith , у большинства программ низкие номера версий, поскольку они не используют семантическое управление версиями.

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

И, предположительно, если мы сделаем этот переход, вы перейдете на SciPy, потому что это следующая часть инфраструктуры? Когда это перестает быть инфраструктурой?

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

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

И почему NumPy и другие части инфраструктуры хотят иметь схему управления версиями, совершенно отличную от самой Python и всей остальной научной экосистемы Python?

Вся экосистема SciPy действительно должна использовать один и тот же подход, который (как мне кажется) является доминирующим в научных вычислениях. Это не относится к библиотекам Python и Python других доменов, которые имеют другие привычки. Например, веб-разработка гораздо менее консервативна, чем научные вычисления. В основном это делают разные люди, которые заботятся о разных пользователях. Язык Python будет единственной точкой контакта.

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

И центральная структура данных стабильна. Подавляющее большинство несовместимых изменений в любом выпуске - это крайние случаи, а не поведение ndarray. См., Например, https://github.com/numpy/numpy/blob/master/doc/release/1.13.0-notes.rst#compatibility -notes. Также обратите внимание, что ни одно из этих изменений не будет иметь никакого значения для системного администратора, поэтому, даже если бы они долго смотрели на эти заметки (если бы это было 2.0.0), они не могли бы решить, подходит ли обновление или не.

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

SciPy использует ту же схему управления версиями и политику устаревания / удаления, что и NumPy. Длительное пребывание в 0.x не означает семвер.

тот, который (как я понимаю) доминирующий в научных вычислениях

Традиционные сравнения экосистемы SciPy проводятся с такими вещами, как Matlab и R. Не могу найти никакой информации о R, но он находится на уровне 3.x и сильно изменился, поэтому, вероятно, не semver. Matlab: точно не семвер.

RE: причудливая индексация. Действительно, для этого можно использовать специальную функцию. Это то, что было сделано в TensorFlow, например, с tf.gather , tf.gather_nd , tf.scatter_nd , tf.boolean_mask и т. Д. Результат немного более подробный, чем перегрузка [] , но наверняка более прозрачная.

Еще одна функция, которая может помочь, - аннотации типов, функция, которая частично была мотивирована сложностью перехода Python 2 на 3.

Я не говорю, что это будет легко. На мой взгляд, последствия для сообщества гораздо важнее. Это действительно потребует много энергии для реализации и последующего внедрения в такие проекты, как SciPy.

@khinsen Я

В настоящее время, благодаря фреймворку Apple Accelerate, минимально необходимая версия LAPACK - 3.1.ish, выпущенная более десяти лет назад. И в настоящее время LAPACK находится на 3.8.0. Тем временем они отказались от целого ряда подпрограмм (устаревших и / или удаленных) и исправили множество ошибок и, самое главное, ввели новые подпрограммы, необходимые для заполнения пробела между коммерческим программным обеспечением и научным программным обеспечением Python. Конечный результат резюмируется здесь . Я постоянно раздражал, в основном, @rgommers и других в течение последних 6 месяцев из-за этого 😃, и я могу заверить вас, если бы они были такими людьми, которых вы, возможно, неохотно изображали здесь, это должно было произойти к настоящему времени и нарушить код многих люди. Вместо этого они терпеливо объясняли, почему не так просто отказаться от поддержки Accelerate.

Теперь есть бесспорная потребность в более новых версиях. Это не обсуждение, и мы можем спокойно пропустить эту часть. Значительная часть пользователей NumPy и SciPy выиграет от этого. Но мы не можем просто отказаться от этого из-за аргументов, которые вы уже представили. Как бы вы разрешили это?

Я не спрашиваю об этом в шутливой форме, но, поскольку все разработчики, похоже, думают одинаково (и я должен сказать, что согласен с ними), возможно, ваш взгляд может дать новую идею. Должны ли мы сохранить Accelerate и создавать новый пакет NumPy / SciPy каждый раз, когда такое случается? Если мы откажемся от поддержки в целях внедрения инноваций, как вы думаете, как лучше всего поступить здесь?

В настоящее время, благодаря фреймворку Apple Accelerate, минимально необходимая версия LAPACK - 3.1.ish

@mhvk , это может быть проблемой для # 9976 в 1,14, для которого, я думаю, требуется 3.2.2 (изменить: переместим обсуждение туда)

@xoviat : Давайте обсудим этот вопрос

@ilayn Спасибо, что

Главный общий момент: есть разные пользователи / сообщества, у которых разные потребности. Некоторым требуется Accelerate, другим нужны новые функции LAPACK. У обоих есть веские причины для своих конкретных приоритетов. Возможно, найдутся люди, которым нужны и Accelerate, и новые функции LAPACK, хотя мне это не ясно.

В мире Fortran / C такой проблемы нет, потому что программные стеки более мелкие. Есть Fortran, LAPACK и код приложения без дополнительных посредников. Что происходит, так это то, что каждый код приложения выбирает конкретную версию LAPACK в зависимости от своих приоритетов. Вычислительные центры обычно хранят несколько версий LAPACK параллельно, каждая в своем собственном каталоге, причем выбор делается путем изменения Makefile кода приложения.

Урок, который мы можем и должны перенять в экосистеме SciPy, заключается в том, что выбор версий программного обеспечения - это задача не разработчиков программного обеспечения, а людей, которые собирают пакеты программного обеспечения для конкретных приложений. В нашем мире это люди, которые работают над Anaconda, Debian и другими дистрибутивами программного обеспечения, а также системные менеджеры на разных уровнях и конечные пользователи с нужной компетенцией и мотивацией.

Итак, я предлагаю решить дилемму SciPy / LAPACK: оставить сегодняшний SciPy с использованием Accelerate, но перевести его в режим минимального обслуживания (возможно, перехватят его другие люди). Люди, которые хотят Accelerate, могут выбрать «SciPy 2017» и быть счастливыми. Они не получат новых функций LAPACK, но, по-видимому, для большинства из них это нормально. Разработка продолжается в новом пространстве имен ( scipy2 , scipy2018 или что-то еще), которое переключается на современный LAPACK. Если технически возможно, разрешите параллельную установку этих двух (и будущих) вариантов (что, я думаю, должно быть возможно для SciPy). В противном случае людям, которые нуждаются в обоих, придется использовать несколько сред (conda, venv или общесистемные среды через Nix или Guix). Обратите внимание, что даже в этом втором сценарии я настоятельно рекомендую изменять пространство имен при каждом несовместимом изменении, чтобы читатели кода Python на любом уровне понимали, для какой версии SciPy был написан код.

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

Общая идея о том, что разработка и сборка выполняются независимо и разными людьми, также предполагает, что сегодняшние мегапакеты следует разбивать на более мелкие единицы, которые могут развиваться с разной скоростью. Сегодня нет причин для NumPy, содержащего небольшой интерфейс LAPACK и такие инструменты, как f2py . Для SciPy может иметь смысл иметь общее пространство имен, указывающее на согласованность и общую политику разработки, но подпакеты вполне могут быть распределены независимо. Подход к созданию мегапакетов восходит к девизу Python «батареи включены», который был великолепен 20 лет назад. Сегодняшняя база пользователей слишком разнообразна для этого, и создание пакетов программного обеспечения считается отдельным видом деятельности. Анаконда должна теперь включать батареи.

Основным препятствием для принятия такого подхода являются традиционные дистрибутивы Linux, такие как Debian или Fedora с их подходом «одна установка Python на машину». Я думаю, что они могут переключиться на несколько общесистемных виртуальных сред с разумными усилиями, но я не особо задумывался об этом. Для меня будущее упаковки программного обеспечения - это системы на основе среды, такие как conda или Guix.

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

• Вы только что воссоздали безумие на следующей картинке
  
  Только что посчитал, и теперь у меня на машине с Windows 27 копий. Теперь умножьте это на 10, поскольку (выпуски здесь чаще) и на 2 (поскольку циклы выпуска NumPy и SciPy независимы). В 2025 году у меня легко будет 15 копий каждой библиотеки и 10 LAPACK и 5 f2pys в качестве зависимостей. Не говоря уже о бремени обслуживания, которое ложится только на группу из десятков человек в обоих пакетах, это просто не сработает. (C ++ не актуален, вставьте любую стандартную библиотеку чего угодно). Спросите любого разработчика коммерческого кода для Win и скажите им, что это хорошая идея. Я не несу ответственности за то, что последует за этим обменом.
• Затем вы увеличили степень детализации пакетов и теперь все работают самостоятельно с разными версиями пакетов; f2py что-то сломал в одной версии, поэтому SciPy перестает строиться в следующей, но все еще зависит от более ранней версии NumPy. Так что какая-то целостная сущность должна собрать их бесплатно.
• Затем вы также сделали Anaconda (или какое-то другое лицо) компанией с большой зависимостью, как и Accelerate. Или просто будет много «чужих».
• Затем вы мобилизовали большую часть пользовательской базы в рабочий процесс, который им действительно не нужен (в том числе и я), с использованием виртуальных окружений.
• Затем вы даже попутно модифицировали операционные системы Linux (что ... я имею в виду, просто прочтите их списки рассылки, это весело).

Может, вы немного отвлеклись.

(Это стало общедоступным обсуждением, поэтому я продолжу и перейду к нему).

Проблема с сохранением поддержки ускорения не в том, что ему не хватает новых API LAPACK. Если бы это была проблема, мы могли бы поставить новые прокладки LAPACK и все. Проблема в том, что есть базовые функции, которые возвращают неверные результаты в определенных сценариях. Нет другого способа обойти это, кроме написания собственных функций BLAS. И если мы это делаем, нам также может потребоваться OpenBLAS или MKL.

@xoviat Все это обсуждалось в https://github.com/scipy/scipy/pull/6051. Как обычно, никогда не бывает так просто. Но дело не в том, чтобы обсуждать Accelerate drop, а в том, чтобы использовать его как вариант использования для фактического цикла разработки новых версий.

@ilayn Да, я уверен, что уже знаю, о чем я говорю. Но комментарий был для @khinsen; Я думаю, у него сложилось впечатление, что мы действительно можем сохранить поддержку Accelerate.

Можно утверждать, что особенность (или ограничение) экосистемы Python состоит в том, что вы получаете одну версию библиотеки без ужасного взлома, связанного с изменением имени. Это происходит в ядре Python. Вот почему существуют библиотеки с именами _lib_ и _lib_ 2, которые имеют одинаковое назначение, но отличаются API. Так работает даже рудный Python. Невозможно смешивать стандартные библиотеки между версиями, даже если обе технически можно использовать на современном Python без того, чтобы кто-то скопировал их и не поместил на PyPi. По этому поводу есть множество вопросов на

@ilayn Если по какой-то причине вы хотите, чтобы на вашем компьютере были все возможные комбинации всех версий всего, да, это беспорядок. Но зачем вам это нужно? Если вы ограничитесь комбинациями, которые вам действительно нужны для сценариев вашего приложения, держу пари, что их будет меньше. В качестве примера у меня на компьютере есть ровно две среды Python: одна с Python 2 + NumPy 1.8.2 для запуска моего кода 20-летней давности, а другая представляет собой современное состояние примерно двухлетней давности для всего остального ( два года назад, потому что я установил его два года назад и никогда не видел причин для обновления после этого).

Что касается детализации, возможно, я был не совсем ясен в своем предложении. Я выступаю за большую детализацию в упаковке, а не в разработке. Я бы ожидал, что разработка, скажем, f2py и SciPy будет продолжаться в тесной координации. f2py-2018 и SciPy-2018 должны работать вместе. Это не значит, что они должны быть упакованы как единое целое. Цель состоит в том, чтобы предоставить менеджерам по распространению программного обеспечения больше свободы в выполнении их работы.

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

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

Кстати, я на самом деле слежу за списком рассылки одного дистрибутива Linux (Guix). Не очень весело, но много практической работы. Я счастлив, что есть люди, которые этим занимаются.

@xoviat Я не предлагал «сохранить поддержку Accelerate». Я просто предлагаю сохранить вариант SciPy (в значительной степени текущий) не как устаревшую версию для музея, а как вариант, представляющий интерес для определенной группы пользователей: для тех, для кого использование Accelerate более важно, чем решение проблем, которые Accelerate создает для других. Людям, которые хотят ускориться, придется смириться с последствиями своего выбора. Некоторые проблемы никогда не будут исправлены для них. Вероятно, это их устраивает («известные ошибки лучше, чем неизвестные»), так зачем заставлять их делать что-то другое?

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

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

Я предлагаю разработчикам программного обеспечения принять эту реальность, а не отрицать ее. Им следует разрабатывать (и, прежде всего, упаковывать и маркировать) свои продукты для разнообразия мира.

@khinsen Если вас И даже если это не так, что произойдет, когда кто-то в будущем обвинит SciPy в проблеме с ускорением? Что происходит, когда кто-то хочет съесть свой торт и тоже его съесть? Я просто вижу, как это происходит.

@xoviat Нет, меня не устраивают неправильные результаты функций линейной алгебры. Но я уверен, что есть много пользователей SciPy, которым затронутые функции вообще не нужны. В теме, о которой вы говорили, кто-то предложил удалить / деактивировать затронутые функции при обнаружении Accelerate, что, на мой взгляд, является хорошим решением (примечание: я не могу судить об усилиях, необходимых для реализации этого).

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

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

У этого утверждения минимальные доказательства, и я бы фактически сделал ставку на обратное. Функции широко используются, но дают сбой только в определенных сценариях; другими словами, ваши результаты, вероятно, верны, но могут и не быть. Да, это, вероятно, относится к SciPy, который вы в настоящее время установили при использовании OSX. Да, это нужно исправить.

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

На самом деле, я думаю, что Anaconda SciPy скомпилирована с MKL, поэтому в этом случае вас не коснется. Но зачем тогда вам нужна ускоренная поддержка?

@xoviat Похоже, здесь произошло большое недоразумение. У меня нет никаких личных интересов в этом конкретном вопросе. Я не использую никаких программ линейной алгебры от SciPy.

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

@xoviat Поддерживать отдельную ветку легко для всех. Нет необходимости размещать его в одном репозитории GitHub. Другими словами, дело не в ветвях. Проблема заключается в размещении имен, чтобы сделать параллельное существование отдельных версий SciPy прозрачным для пользователей (и ассемблеров дистрибутива).

Сегодня, когда вы видите код, говорящий «import scipy», вы не представляете, для какого диапазона версий SciPy он должен работать (т.е. был в некоторой степени протестирован). В лучшем случае есть README с надписью «SciPy> = 0.8» или что-то в этом роде. Эта привычка основана на предположении, что «более высокие» версии всегда «лучше» и никогда ничего не ухудшают (ломают, замедляют и т. Д.). И это предположение просто неверно.

С другой стороны, если в коде написано «import scipy2017 as scipy», то каждому читателю ясно, что его использование с более ранними или более поздними версиями может привести к неприятным сюрпризам. И если старые версии SciPy исчезнут (фактически, из-за отсутствия поддержки), то такой код выйдет из строя с сообщением об ошибке, а не продолжит работать ненадежно.

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

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

Я полагаю, что создание такого типа дополнительных пакетов возможно. Я также ожидаю, что это просто создаст ад другого типа. Многое может выжить, но проверка типов, например, не будет и не может, когда вы смешиваете две версии, поэтому в основном вы не узнаете, может это работать или нет, пока вы не попробуете (и никто не будет это проверять!).
И если вы не предлагаете смешивать две версии, я думаю, что ваше решение scipy2017 только ухудшит ситуацию. Похоже, что нам понадобится что-то вроде выбора динамического / динамического виртуального окружения (например, pin_import_version("1.6<numpy<1.10", level="raise") перед любым импортом на уровне Python).

Конкретный импорт имеет смысл, если у вас есть серьезные запретительные изменения (немного как py2 / py3), и мы уже видели, что у нас разные мнения о том, где и в каком временном масштабе кажется эта «основная» линия.

Была представлена ​​обратная совместимость NEP # 11596, можем ли мы закрыть это?

Была представлена ​​обратная совместимость NEP # 11596, можем ли мы закрыть это?

Да, мы можем закрыть это. Независимо от этого NEP (который явно упоминает semver как отвергнутую альтернативу), основные разработчики согласны с тем, что мы не хотим переходить на semver. Следовательно, закрытие как wontfix.

Всем спасибо за обсуждение.