Доступен релиз Python-библиотеки для научных вычислений NumPy 1.22, ориентированной на работу с многомерными массивами и матрицами, а также предоставляющей большую коллекцию функций с реализацией различных алгоритмов, связанных с использованием матриц. NumPy является одной из наиболее востребованных библиотек, применяемых для научных расчётов. Код проекта написан на языке Python с применением оптимизаций на языке Си и распространяется под лицензией BSD...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=56463
одно из лиц СПО, долгих лет как говорится
Если бы они перешли на копилефт, было бы ещё замечательней.
Осмелюсь просить предоставить примеры других частей тела СПО
> Прекращена поддержка Python 3.7Впереди паровоза. Куда так спешить. Вот мы только на 3.7 начали переходить. Безумцы.
>Вот мы только на 3.7 начали переходитьтаких "вас" надо гнать из профессии сс#ными тряпками
Гнать нас сишарпными тряпками?
Мы сами кого хочешь выгонем, и одних уже выгнали. Теперь мы работаем меньше чем они, получаем больше, а заказчик теперь и слышать не хочет про сишарп, хотя те ребята которых мы выгнали были самыми современными сишарпниками на стероидах. Да и в Астрашляпу питон 3.8 не подвозят, а самим тащить это всё лень. Нет, вы конечно можете всё это тащить на себе, но зОчем?
кто-то забзделся в своих влажных мечтах, а сам до сих пор не умеет даже в аннотации типов нормально, потому и не спешит переходить
> не умеет даже вя кто-то не умеет по-русски разговаривать, ичо?
кстати, в сишарпе до сих пор для вывода строчки в консоль нужно целый класс городить?
Важно не то, сколько строчек занимает Hello World, а на сколько сотен-тысяч жопочасов больше занимает поддержка большой кодовой базы на скрипти языке по сравнению с JVM/DotNet и т.п.Кстати вот для таких двоечников типа тебя Microsoft даже сделал то, о чем ты пишешь:
https://docs.microsoft.com/ru-ru/dotnet/csharp/whats-new/tut...
Не поверишь, такое есть даже VisualBasic.NET:
https://docs.elementscompiler.com/Mercury/LanguageExtensions.../
А теперь давай представим, насколько сложно сделать из скрипти Питона что-то стоящее для крупных проектов.Но и тут на помощь приходят технологии Microsoft:
> Но и тут на помощь приходят технологии Microsoft:
> https://ironpython.net/Я думал оно давно уже загнулось, а оказывается в прошлом году был релиз.
Но я больше жду когда Microsoft CPython улучшит, как анонсировал. (то что у них получится, не сомневаюсь)
> по-русски разговариватьНаименее востребованный навык в IT. Даже вредный иногда — оепутаци
> по-русски разговариватьНаименее востребованный навык в IT. Даже вредный иногда — репутация у «по-русски разговаривающих» так себе, рабочая этика и того хуже, денежная клиентура с такими предпочитает без промежуточных галер не общаться. Такие дела…
Уже нет. Не нужно
Нет, уже не нужно. Но долго они к этому шли.
Звиняюсь за двойное сообщение.
>Теперь мы работаем меньше чем они, получаем большеКакой сказочник. Что бы энтерпрайз платил питонщикам больше чем шарпистам, и при этом отказывался от с# в пользу питона с его gil это из области фантастики.
Этот твой еньтепрайзъ от слово Дата Сайнтист сразу обоссывается от радости и начинает деньги пихать сразу в трусы. А ты говоришь шарп. Шире надо смотреть на мир.
Какой такой GIL, понимаешь:https://stackoverflow.com/questions/3429159/python-requires-...
Так о разных вещах говорите. Python - для прототипирования, а C# - для продуктива.
смузихлёбство и погоня за версиями ради версий.
Так переходите на 3.8 сразу, в чём проблема?
3.8 собственно последний нормально работающий на W7, в т.ч. x32
Зачем на 3.8? Сразу на 3.10.1.
3.10 также поддерживает Windows 7 и нормально в этой операционке работает!
какую версию PIL/pillow можно поставить на 7-ку без сервиспаков?
Без сервиспаков Windows 7 давным-давно не поддерживается. Обновляй до SP1 и нормально работай!
Ну так и Numpy тоже не обновляй.
А ты будь прогрессивным. Переходи на новую версию Питона.
В чем проблема перехода с другой версии 3.х?
% grep "NUMPY" -r /var/db/ports
/var/db/ports/graphics_vigra/options:_FILE_COMPLETE_OPTIONS_LIST=DOCS FFTW HDF5 NUMPY OPENEXR PNG JPEG TIFF
/var/db/ports/graphics_vigra/options:OPTIONS_FILE_UNSET+=NUMPY
/var/db/ports/x11-toolkits_py-gtk2/options:_FILE_COMPLETE_OPTIONS_LIST=DOCS EXAMPLES NUMPY
/var/db/ports/x11-toolkits_py-gtk2/options:OPTIONS_FILE_UNSET+=NUMPY— не нужен.
Ты не нужен
О да какой проект по ML не возьми, то версия торча не та то еще что-то не то. А нужный торч есть только под питон 3.7 и там начинается что кто-то из либ под 3.7 уже не работает надо искать ту версию что работает. Качать с левого репо питон 3.7. Похоже эта музыка будет вечной.
Учоные никогда не умели в нормальное программирование. Инструментарий им под стать.
Вот как раз торч и тензорфло пишут программисты. И да, могу подтвердить, там полная Ж с зависимостями. В которую еще и нвидия со своей кудой добавляет.
Проблемы с торчем прошли, когда они дропнули луа. С кудой никаких проблем никогда нет. Bliss не компилируется, я не знаю почему, с бинарями ок. С numpy была небольшая проблема, когда в последней бете 3.10 немного сломали, но исправили быстро. Тензорфлоу у меня тоже не компилируется кстати, с торчем реально никаких проблем.
Если бы они ещё совместимость сохраняли более менее. Но нет чуть поменяешь версию у тебя весь проект в каких то ошибках, то депиркейдет удалили то функции нет.Еще SciPy с версиями шалит. Ужыс короче.
учоные это бывшие студенты на одном месте верченые
Учёные работают, а не красоту в коде наводят.
Для ученых есть Джулия. А студенты как-нибудь и с Питоном разберутся.
Русскому учёному нужно только 7 вещей: бумага, карандаш, ластик, линейка, ручка, умный вид, и кулак по морде от начальства.
Это только в последние лет 15-20 актуально стало. Да и то, не везде.
Всё, FORTRAN и Matlab уже не нужены.
Видел как из питона вызывали и фортран и матлаб. Так что все надо все тащите все заработает.
Отличная библиотека для простого ЯП, понятного и доступного для любого астрофизика или ксенобиолога.
Да любая собака на питоне писать может. Профессор Павлов не дал бы соврать.
Вот она истина в одной фразе. Python оптимален для тех, для кого разработка не является основным видом профессиональной деятельности. Потому фраза "профессиональный программист на Python" меня и вводит в ступор.
У питона с управлением зависимостями прям беда: setup.py, pip, pipenv, poetry и прочая хрень. Сейчас ещё добавили project.toml. А pip как не умеет по нормальному дерево зависимостей отображать, так и не умеет.
Ну все, началось. Множество апологетов "золотого молотка" начали минусовать посты, так как кроме аргумента, что "золотой молоток" - это круто, у них иных аргументов нет.
Это прямо беда среди разработчков - махать любимым "золотым молотком" искренне не понимая, что универсальных языков программирования не бывает. И ограничивая свою деятельность одним языком программирования они сами себя дисквалифицируют. Каким бы замечательным этот язык не был.
Никто и не говорит, что тот же питон универсален. Однако, это факт, что он универсален и удобен, особенно, с учётом интеграции нативного кода. Скорее, не везде применим из-за низкой производительности. Единственный недостаток питона. Этой низкой производительности достаточно всего лишь почти везде -- когда нагрузки возрастают, там можно и подумать о переписывании (благо, это не разрабатывать с нуля).Я вполне могу представить себе профессиональных питон-программистов, точно так же, как и профессиональных жс-программистов. Им просто нет необходимости выходить за рамки интерпретируемой шляпы, скорее всего, они способны на это при должном уровне квалификации. Язык, на котором писать, вообще не главное.
Вот что действительно непонятно, так это то, о чём ты рассуждаешь, будто успокаиваешь себя в стиле "вот я-то умею на паскале писать, это лучше!", при этом сложность этих паскаль-приложений будет на много порядков ниже (даже если отбросить все эти тысячи слоёв абстракций, абстракции далеко не всегда плохо конечно).
> вот я-то умею на паскале писать, это лучше!Соболезную, как экстрасенс Вы с треском провалились.
Я только чужой код на Pascal/Delphi поддерживал, сам предпочитая другие языки, включая, тот же Python. Но ограничивать свою деятельность исключительно последним мне никогда даже в голову не приходило. Иногда просто необходим C, причем вплоть до необходимости ассемблерных вставок, иногда быстрее написать на tcl/tk, есть задачи для которых лучше C# или Java, а в браузере проще использовать JS (или TS).
Всю жизнь я выбирал и выбираю инструмент, в зависимости от задачи, а не пытаюсь все задачи подряд решать одним "золотым молотком", как Вы.
Золотой молоток это всегда хорошо. Чем быстрее получается хороший вылизанный код, и чем проще он в сопровождении, тем лучше. Всё зависит только от качества и актуальности батареек, на каком языке разрабатывать вообще не принципиально (главное, чтобы не си с его бойлерплейтом и байтобством, можно плюсы взять), однако время, необходимое на разработку, это существенный параметр. Невозможно знать всё языки достаточно хорошо, придётся выбирать специализацию. Не навсегда, конечно. Те, кто вчера использовал перл, сегодня перешли на питон. Всерьёз сравнивать скриптоту с компилируемыми не могу, уж извините.
> Золотой молоток это всегда хорошо.Спасибо, что потвердили мои слова. Вообще-то "золотой молоток" есть антипаттерн проектирования, что признано значительным количеством специалистов, например, таких как Каплан или Маслоу.
Вымышленные термины, они такие. В жизни не всё так просто. Если рассматривать с позиции затрат и вероятности получения хороших результатов, стесняться отдавать предпочтение технологиям, которые точно работают и которые дадут предсказуемый результат, было бы довольно не умно.
Если Вы, конечно, работаете в шарашкиной конторе, в которой три разработчика, то выбора у Вас нет. Потому и защищаете свой антипаттерн.А в нормальных системных интеграторах не составляет проблем подобрать в проектную команду специалистов, уже имеющих компетенцию в выбранных инструментальных средствах. Или даже оплатить обучение специалистов, если выбрано относительно новое инструментальное средство.
В проектной деятельности так же существуют требования заказчика. Например, если заказчик по требованиям импортозамещения выбирает PostgreSQL, а проект требует разработки дополнительных копилируемых SQL функций, то как бы Вы не были против С, альтернативы тут Вы не обнаружете. А даже если можно обойтись не компилируемой функцией, то Python Вам не позволят использовать безопасники, так как безопасного Python для PostgreSQL в природе не существует.
Ну вот, начинается. Уже нужны специальные разработчики с улицы, и, как обычно, чтобы вчера готово было. Большинство контор используют что-то одно. Или додиез, или пхп с жс, или даже один 1С. Набрать команду специалистов по коболу, мы гугл что ли? Не подъёмных проектов никогда никто не будет брать, для начала. А ещё, внезапно, не все пашут на галерах, есть компании со своими продуктами.
> Большинство контор используют что-то одно.Да, но разные конторы - разное. Странно, что Вы это не знаете. И если контора не специализируется в разработке и внедрения ПО, то предпочитает обходится недорогими специалистами только в рамках поддержки имеющихся решений. Привлекая системных интеграторов для внедрения новых, развития существующих и для поддержки уже внедренных решений.
Ну и как я уже писал Выше, Python ничем не поможет, если нужно написать CLR функцию для MS SQL или копилируемую функцию для PostgreSQL. А ведь IT ландшафт проекта не ограничивается только БД. Тут будет и kafka c Java, и фронтенд с JS, и многопоточные компилируемые веб-сервисы, и еще многое другое.
> Набрать команду специалистов по коболу
Зачем? Новый проект на COBOL писать сейчас бессмысленно. А моего опыта программирования на COBOL вполне достаточно было пока во всех случаях, когда поддержка COBOL требовалась.
При этом биндинга Python к COBOL я не знаю, поэтому, чтобы не писать новый код на COBOL, использовал C или, в крайнем случе, FORTRAN (с ним биндинг COBOL проще). Все же на них разработка ведется быстрее, чем на COBOL.Могу только утверждать, что зная только один язык программирования, в тех системных интеграторах, в которых мне довелось работать, выше миддла не поднимешься. А уж тимлид и, тем более, архитектор проекта просто обязаны иметь довольно широкий кругозор в языках программирования.