Доступен (https://mail.python.org/pipermail/scipy-dev/2019-January/023...) релиз Python-библиотеки для научных вычислений NumPy 1.16 (http://www.numpy.org/), ориентированной на работу с многомерными массивами и матрицами, а также предоставляющей большую коллекцию функций с реализацией различных алгоритмов, связанных с использованием матриц. NumPy является одной из наиболее востребованных библиотек, применяемых для научных рассчётов. Код проекта написан на языке Python с применением оптимизаций на языке Си и распространяется (https://github.com/numpy/numpy/) под лицензией BSD.NumPy 1.16 объявлен как последний выпуск, в котором сохраняется поддержки Python 2.7. Новые возможности отныне будут добавляться только в ветку для Python 3, а поддержка Python 2 будут ограничена только исправлением ошибок. Сопровождение ветки 1.16 будет обеспечено до 31 декабря 2019 года, после чего возможность дальнейшей поддержки будет зависеть от активности лиц, заинтересованных в продолжении использования Python 2. Напомним, что поддержка Python 2.7 будет прекращена сообществом разработчиков языка Python в 2020 году.
В новой версии (https://github.com/numpy/numpy/blob/master/doc/release/1.16....) проведён рефакторинг кодовой базы, переработана организация кода и улучшена переносимость между разными платформами. Добавлена экспериментальная поддержка переопределения функций numpy производными проектами. Функция matmul переведена в разряд универсальных (ufunc (https://docs.scipy.org/doc/numpy-1.15.1/reference/ufuncs.html)) и может быть переопределена при помощи выражения "__array_ufunc__". Улучшена поддержка архитектур ARM, POWER и SPARC, а также платформ AIX и PyPy. Улучшена переносимость с ctypes. Расширена поддержка PEP 3118 (https://www.python.org/dev/peps/pep-3118/) (интерфейс совместного доступа к буферам).
URL: https://mail.python.org/pipermail/scipy-dev/2019-January/023...
Новость: https://www.opennet.me/opennews/art.shtml?num=50000
юбилейная новость -- и кстати довольно важная!// P.S.: https://pythonclock.org/
Ну ок, Питон2 и так прожил больше, чем предполагалось. Это как 32-битный х86. Нафиг не нужен, но упорно выживает за счёт особо упорных.
Он выживает за счёт тех, кому важна скорость вычислений и потребление памяти, а не номера версий вычислятора.
Самопочином иди занимайся. У питона 2.7 до сих пор скорость вм выше чем у 3.7. Например, тупой вход-выход в/из функции почти в 3 раза медленнее. Активная работа с байтовыми слайсами раздувает в памяти всю третью ветку. У меня, для примера, есть aws lambda. Написана давно и аккуратно. Обычный дата-саентизм уровня "загрузить десяток мегабайт с s3, покрутить массивы в numpy, посчитать производные данные, применить модельку, записать результаты в dynamo".
Версия на 2.7, кушает ~256MiB, работает в среднем 2 минуты и всегда укладывается в 5 минут. Версия на 3.6, не смотря на все приседания и перепиливания, жрёт , не укладывается в 5 минут и выжирает почти гигабайт.
Для дата-сайнтистов есть Julia. По крайней мере, с коннекторами к источникам данных и скоростью предобработки и вычисления там проблем нет.
Ещё раз. Решение есть. Работает. Свою часть работы делает хорошо. Переписывание на более новые версии было затеяно после анонса окончания поддержки амазоном.
Амазону тоже хочется поиметь в 3 раза больше денег на более медленном, но более современно решении
Интересный, кстати, это вопрос. На сколько можно доверять облачному провайдеру поддержку своей логики, если в любой момент времени они могут изменить версии инструментов и сделать эту логику нерабочей.... В части Амазона, это, скорее, сигнал, чтобы не использовать их.
В культуре Питонистов есть зуд к изменениям. Поэтому если вы хотите сделать что-то надолго, то брать Питон нежелательно. Не из-за недостатков языка, а потому, что они хотят улучшать и улучшать, очень часто не оглядываясь на обратную совместимость.
Уж кто кто а питонисты сделали очень многое, чтобы сгладить переход.
> Уж кто кто а питонисты сделали очень многое, чтобы сгладить переход.А у C++ников вообще никакого перехода нет.
здрасьте, как это так нет, когда каждый год новый стандарт?
У c++ников ситуация проще только потому, что никому кроме разработчика и опакечивателя это неинтересно, бинарник не требует (обычно) весь интернет зависимостей и специальную версию рантайма (оставляя за рамками гемор с libstdc++.so.7.6.5.6.7.8.0.1245 непременно линкуемой по этому имени, хотя рядом лежит просто .so ), а компилятор умеет флаги совместимости (хотя это и не всегда помогает, даже если удается угадать, чего ему на самом деле сегодня надо)
P.S. желающие могут смеху ради попытаться собрать apache 1.3.какойтамбыл - и удивиться. Да, это plain c.
ага, то-то примеры из книжки страуструпа ты современным компилятором не скомпилируешь.
Чтобы сделать надолго, не надо прицеплять внешний рантайм. Внезапно, даже в glibc умудрились устроить революцию, в прошлом году превратив функцию чтения каталогов в не реентерабельную (как это по-русски "thread-safe"?).* Контр-аргументом можно ткнуть в перл. Но:
С перлом скорее "повезло" (язык практически остановился в развитии и код из 90-х всё ещё может быть выполнен современным рантаймом). Увы, молодое поколение перл похерит. Из более-менее стабильного внешнего рантайма т.о. остаётся shell+awk. Где-то этого хватит. А где нет? Или подстраиваем свою конституцию под прокрустово ложе golang. /Гугл первым (после borland) догнал назначение статической сборки./ Или учимся собирать статикой что-угодно-ещё.
погоди, у нас же уже есть прекрасный perl6 ?!
Он, правда, в сферическом вакууме есть, но я в них верю, они смогут произвести такую революцию, что камня на камне не оставят.> Или учимся собирать статикой что-угодно-ещё.
начни с glibc - и удивись результату.
У golang есть то преимущество, что ни от чего кроме загрузчика они не зависят, весь мир с нуля.
> погоди, у нас же уже есть прекрасный perl6 ?!Эти старпёры не догадались объявить perl6 заменой perl5. А может, заложенные в модель требования к рантайму помешали.
> начни с glibc - и удивись результату.
Да. Но после разгрома LSB (пока) осталась опция "тащи свой glibc etc. рядом с софтиной". Про это всякие flatpack'и.
> У golang есть то преимущество, что ни от чего кроме загрузчика они
> не зависят, весь мир с нуля.А так же, из "одноразового" кода (что-то сделал и помер) можно выкидывать GC. Работает вполне шустро: в моём последнем кейсе "прогуляться в ldap с несколькими вопросами и причесать результат" съело порядка 5мс user+sys при 9МБ RSS (сравнимо с питоном и вдвое легче перла, но минимум на порядок жирнее того что можно собрать на сях).
Но: golang "в нагрузку" жёстко опускает "потолок" допустимого в коде. Ладно, я не программист — переживу. Но профессионалы от этого будут бегать 100%.
> смогут произвести такую революцию, что камня на камне не оставят.Конкурент брайнфаку таки растет?
R и data.table - засасывает гигабайнтный csv за десятки секунд.
Или все еще в уме надо отлаживать?
давай прувы, трепло, конкретный код давай, показывай, что, где и с какой скоростью работает
Он выживает за счет "коммерческого" говнокода, на сопровождение которого забили.
Я могу объяснить, как это так получается. В культуре Питонистов есть страсть к изменениям, это лагерь фактически противоположный C++ному. Эта страсть к изменениям в сочетании с традиционной для кровавого энтерпрайза тяги к развесистым программам и с динамической типизацией языка Питон приводят к тому, что приходится жёстко фиксировать версию интерпретатора и библиотек.Но тут на помощь приходит python 2.x - эта ветка считается мёртвой, поэтому библиотеки под неё питонисты модифицируют не так интенсивно. Поэтому типичный "кроваво-энтерпрайзный софт" более-менее живёт годами, иногда выживая даже при смене младших версий интерпретатора (2.6 -> 2.7).
интересно а сколько стандартов С++ поменялось за последнее время? последний стандарт так и вообще создатель ++-в сказал считать новым языком фактически)) точно бредит.
я например и с++ и питон использую. и не вижу ничего плохого. для каждой задачи свой инструмент.
в новости забыли указать, что также выброшена поддержка python ниже 3.5, т.е. те, кто на debian jessie идут лесом)
И кто на XPюше - тоже.
Те, кто на XPюше, они без браузеров даже, не говоря уж об остальном.
Да хрен с ним с браузером. Рулить древней аппаратурой с древними дровами как?
а у вас там что - 2.7 уже выпилен?ну, значит, страдальцам у которых немое кино уже кончилось, а звуковое не настало, придется страдать. Страдание очищает.
ну так они и так лесом давно пошли в общем-то
https://news.softpedia.com/news/debian-gnu-linux-8-jessie-wi...
>Проблема связана с небезопасным использованием модуля "pickle".Безопасное использование модуля pickle почти бесполезно.
> те, кто на debian jessieпокажите мне этих героев
Хороший мудератор: вот в этом вся суть рашен опенсурс - ответа хрен, лучше удалить вопрос.Как это собирать? На стадии configure пишет, что не может создать исполняемый файл. По интернетам масса таких вопросов, все без ответа.
С компилятором/binutils всё норм - сотни пакетов собираются нормально.
> На стадии configure пишет, что не может создать исполняемый файл.Если исключить тривиальную ошибку, это чаще всего означает, что компилятору скормили флаг, который он не знает. А это чаще всего бывает тогда, когда компилятор слишком старый.
это чаще всего означает, что компилятора нет вообще. Поскольку альтернативно-одаренный вряд ли догадался что ему нужен gfortran.но в любом случае ответ на этот вопрос лежит в логе конфигурялки, в который альтернативно-одаренный питонист не умеет посмотреть.
кстати, зачем альтернативно-одаренные его пересобирают, когда на сайте лежат новые вилы под все возможные и некоторые невозможные платформы, тоже загадка
Ну как зачем, разве разработчики библиотеки могут собрать бинарники лучше, чем Вася Пупкин с опеннету? Удивляюсь я.
Какой ты вумный...gcc --version
gcc 7.3.0В той же системе numpy-1.10.4 собрался успешно.
Если что, fortran - опция.
> gcc --versionА что говорит gfortran --version ? В зависимостях соответствующего Debian-пакета gcc не значится, только gfortran. И так уже давно.
gfortran --version
GNU Fortran 7.3.0
>> gcc --version
> А что говорит gfortran --version ? В зависимостях соответствующего Debian-пакета gcc не
> значится, только gfortran. И так уже давно.ну так может (коли ты юзер дебиана) пойдешь дашь п-ы пионерам? (в смысле - хоть тикетца им заведи?)
Потому что по факту - хрен ты его соберешь без gcc. И без g++,кстати, тоже - причем сборочница этого, к моему смеху, не проверила - просто навернулась по дороге.
под волшебной бубунточкой, если что, собрался.
> ну так может (коли ты юзер дебиана) пойдешь дашь п-ы пионерам? (в смысле - хоть тикетца им заведи?)Не надо: gfortran зависит от gcc.
Если что, только что пересобрал на этой машине numpy-1.10.4 - успешно.
> Какой ты вумный...да блин, нафиг мне твоя версия - в лог посмотри, он им гадит прямо туда где собирается.
Прямо в последних строчках и будет причина.
> это чаще всего означает, что компилятора нет вообще.Этот вариант я отнёс к:
> > Если исключить тривиальную ошибку
>> это чаще всего означает, что компилятора нет вообще.
> Этот вариант я отнёс к:
>> > Если исключить тривиальную ошибкукакая ж она тривиальная, если вон, дебианы взяли и забыли зависимость включить, как нам сообщают с полей? ;-)
Она была бы лишней (см. выше).
Для истории: сборка проходит успешно, если явно выставить переменную окружения
SHELL=/bin/bash
читайте логи конфигуры, истино вам говорю - они рулез.у меня SHELL вот ни разу не bash, и /bin/sh тоже не баш. Собирается.
Во непруха, это че теперь все скрипты переписывать на python 3 до 2020г.?
С питона вообще давно пора слезать. Зачем что-то на него переписывать?
Давно пора.
Дайте пж майн 1.16