Я сам вовсю пользуюсь pytest, you're preaching to the choir. Просто как по мне, так лучше многословность Джавы, чем вот эта ситуация, когда буквально каждый идентификатор в библиотеке − это самобытное сокращение.
То есть все эти asarray, infstr, nditer, ma − это всё общепринятые математические символы?
А то, что функции NumPy игнорируют возможности Python по обращению с аргументами и требуют всё приводить к единственному аргументу-последовательности вместо args − это тоже питонично? Вот это, например, как следствие: github.com/numpy/numpy/issues/6555?
У иммутабельных типов в Python нет метода 'append'. Он есть у мутабельных. Называть так метод, создающий новый объект, как минимум неконсистентно. А по-честному, так это просто сбивает с толку пользователей.
NumPy вообще-то непитоничен и в более простых вещах, например, не придерживается PEP-8 в именованиях методов и параметров, и насыщен сокращениями вплоть до полной нечитаемости. Откройте справочник и убедитесь.
Я не уверен, зачем это так сделано, но полагаю, что это должно было как-то помочь пользователям MatLab или Fortran перейти на Python. Если можете, просветите меня в этом вопросе. Но говорить, что NumPy питоничен − это просто отрицать очевидное.
Вы неправы. В других ЯП, например, JavaScript, есть много API, построенных на том, что методы всегда возвращают ссылку на объект, для которого были вызваны. Этот приём называется method chaining. Программисты, привыкшие к нему, пытаются применить его в Python − чаще всего безуспешно, в Python это не принято.
Стандартные библиотеки Python обычно построены с учётом принципа CQS. Python-программисты обычно привыкают к нему. Это позволяет создавать простые и интуитивно понятные API.
NumPy нарушает этот принцип без видимых на то причин, он непитоничен, поэтому им трудно пользоваться.
Вообще, контрагент — это покупатель ИЛИ продавец. А у Вас «И».
Ну, с «ИЛИ» вроде нигде проблем нет: это их общий базовый класс. Я думал, вы имеете в виду «И».
Что касается makemigrations/migrate, то оно по-любому не потянуло бы мою сложную переукладку данных. Всё равно пришлось бы собственно перенос данных рисовать вручную, и делался бы он не групповыми запросами, а пообъектно. То есть в десятки раз дольше. Или сотни.
Если нужно как-то небанально преобразовывать данные, то мы так же делаем `makemigrations` и `migrate`, только между ними мы вписываем в миграцию только тот код, который работает с данными. И не обязательно работать «пообъектно», любые запросы также доступны в этом коде, можно использовать «пакетный» режим (limit/offset) и т. д. И при этом всё правильно оборачивается в транзакции, так что не нужно думать об обработке исключений. Всё это в любом случае упрощает работу и не заставляет идти на компромисы по скорости.
Главное чучелко — это то, что невозможно по-настоящему крепко подружить математику и не-математику.
Что вы имеете в виду под не-математикой? ООП разве не построено на основе теории множеств?
Как-то сразу приучил себя предохраняться.
Так ведь и не надо приучать, если можно пользоваться инструментами, исключающими ошибки.
Чисто по практике: рефакторинг с отказом от ORM зачастую в разы улучшает производительность именно за счёт более оптимизированной работы с СУБД.
Разумеется, у меня нет такого опыта − переписывать проект с выбрасыванием из него ORM, я даже не слышал о таких проектах, да и не стал бы в таком участвовать.
Мой практический опыт говорит мне, что, во-первых, на один неоптимальный запрос, полученный с помощью ORM, приходится сотня запросов, которые ORM сгенерирует оптимальнее, чем программист с первой попытки, и уже этим использование ORM оправдывает себя. Во-вторых, отдельные запросы всегда можно оптимизировать, и тут обычно есть выбор: улучшить код, использующий ORM, либо включить «сырой» SQL в конкретный запрос. Об отказе от ORM в обоих случаях речи не идёт. Ну, и, в-третьих, у любой оптимизации есть границы применимости. А то ведь можно всё на Ассемблере переписать, без SQL, будет ещё быстрее.
А что миграции? Вы о чём? Об ETL или об автоматическом апдейте структуры базы?
Базовую идею ООП можно попытаться сформулировать примерно так: поскольку мир состоит из объектов, то его, этот мир, было бы удобно моделировать созданием объектов внутри программной системы.
Ну зачем так передёргивать? Человек рассматривает окружающий мир как совокупность объектов, поэтому программировать ему тоже может быть удобней при помощи объектов.
ООП − это плохо, поэтому ORM − тоже плохо. Однако ООП широко применяется на практике, поэтому нам придётся с ним считаться. Распространить тот же принцип практической применимости на ORM автор почему-то не хочет,
ORM не является проблемно-ориентированным, поэтому не нужен,
задачу независимости программы от конкретной СУБД уже решали раньше (на самом деле ODBC весьма хреново решает эту задачу по сравнению со многими ORM, ну да ладно),
абстрактный мэппинг − это слишком сложно, мы лучше сделаем много ситуационных мэппингов, типа «средний объём продаж за заданный период», и будем потом весь этот код поддерживать,
и т. д.
Разумеется, список проблем, которые решают (успешно, на практике) ORM у автора далеко не полон. Вот только наиболее очевидные для меня:
безопасность запросов (в смысле изоляции от пользовательского ввода),
оптимизация обращений к СУБД (каскадное конструирование запроса, отложенное выполнение),
миграции!
Лично мне прочувствовать пользу ORM на практике помогло написание нескольких небольших проектов на Python без ORM. Начав писать свой абстрактный уровень поверх MySQLdb, я понял, что занимаюсь ерундой. Сравнивая Django ORM, SQLAlchemy или PonyORM с тогдашними моими экзерсисами, я понимаю, что ORM − не кошмар и не гиря на ноге, а реальные помощники в работе, пусть и не идеальные.
Как сделать так, чтобы pip, установленный вместе с Python 3.6 c python.org, знал, где искать компилятор, либы и хедеры. Игрался с путями, менял версии − бесполезно. Windows детектится, компилятор − нетъ.
Конечно, конечно. Мне однажды было надо, я пару дней убил − не разобрался. Потом поставил mingw64 и сделал всё, что надо было, без разбирательств.
Потому что прыгать по сцене и кричать “Developers! Developers!” мы можем, а сделать систему удобной для разработчика − «У вас далеко не типичная задача, пройдите нахер, товарищ!»
Да, я хочу, чтобы их скачивали абсолютно все пользователи, как это делается в линуксах, макоси, BSD4.3-производных, Солярисе и т. д. Никого почему-то не смущает стандартный компилятор, только в Microsoft-мире все уверены, что без него лучше.
Хотя я не думаю, что набор CLI-средств разработки на самом деле должен весить гигабайты, в других системах всё на 2-3 порядка скромнее. Но тут Microsoft виднее, конечно.
Microsoft, да включите вы уже в Windows стандартный компилятор C (CLI), чтобы питонисту для установки любого пакета с C-расширением из исходников (или для написания своего) не надо было плясать с бубном и скачивать гигабайты VS. А как установить Python, мы уж как-нибудь сами разберёмся.
Вы не учитываете тот факт, что посетители Хабра − в основном профессионалы с синдромом самозванца. Они паникуют, когда возникает необходимость задать вопрос на форуме производителя компонента, или даже при виде даташита. Поэтому они заходят сюда за профессиональной информацией, надеясь, что она будет хорошо замаскирована под «как я провёл лето» и не вызовет приступа.
То, что NumPy не просто чужероден, а выглядит как жертва обфускации, я могу объяснить только тем, что он, возможно, скопирован с Fortran.
А то, что функции NumPy игнорируют возможности Python по обращению с аргументами и требуют всё приводить к единственному аргументу-последовательности вместо args − это тоже питонично? Вот это, например, как следствие: github.com/numpy/numpy/issues/6555?
NumPy вообще-то непитоничен и в более простых вещах, например, не придерживается PEP-8 в именованиях методов и параметров, и насыщен сокращениями вплоть до полной нечитаемости. Откройте справочник и убедитесь.
Я не уверен, зачем это так сделано, но полагаю, что это должно было как-то помочь пользователям MatLab или Fortran перейти на Python. Если можете, просветите меня в этом вопросе. Но говорить, что NumPy питоничен − это просто отрицать очевидное.
Гвидо не любит цепочки вызовов: I find the chaining form a threat to readability.
Стандартные библиотеки Python обычно построены с учётом принципа CQS. Python-программисты обычно привыкают к нему. Это позволяет создавать простые и интуитивно понятные API.
NumPy нарушает этот принцип без видимых на то причин, он непитоничен, поэтому им трудно пользоваться.
Ну, с «ИЛИ» вроде нигде проблем нет: это их общий базовый класс. Я думал, вы имеете в виду «И».
Если нужно как-то небанально преобразовывать данные, то мы так же делаем `makemigrations` и `migrate`, только между ними мы вписываем в миграцию только тот код, который работает с данными. И не обязательно работать «пообъектно», любые запросы также доступны в этом коде, можно использовать «пакетный» режим (limit/offset) и т. д. И при этом всё правильно оборачивается в транзакции, так что не нужно думать об обработке исключений. Всё это в любом случае упрощает работу и не заставляет идти на компромисы по скорости.
Это называется «множественное наследование».
Писать код не надо:
Так ведь и не надо приучать, если можно пользоваться инструментами, исключающими ошибки.
Разумеется, у меня нет такого опыта − переписывать проект с выбрасыванием из него ORM, я даже не слышал о таких проектах, да и не стал бы в таком участвовать.
Мой практический опыт говорит мне, что, во-первых, на один неоптимальный запрос, полученный с помощью ORM, приходится сотня запросов, которые ORM сгенерирует оптимальнее, чем программист с первой попытки, и уже этим использование ORM оправдывает себя. Во-вторых, отдельные запросы всегда можно оптимизировать, и тут обычно есть выбор: улучшить код, использующий ORM, либо включить «сырой» SQL в конкретный запрос. Об отказе от ORM в обоих случаях речи не идёт. Ну, и, в-третьих, у любой оптимизации есть границы применимости. А то ведь можно всё на Ассемблере переписать, без SQL, будет ещё быстрее.
Второе.
Ну зачем так передёргивать? Человек рассматривает окружающий мир как совокупность объектов, поэтому программировать ему тоже может быть удобней при помощи объектов.
Дальше, впрочем, не лучше.
Есть отличная статья в Википедии: Object-relational impedance mismatch. Там собрана серьёзная, качественная критика ORM:
Но уважаемый maslyaev вместо критики предлагает нам набор соломенных чучелок:
Разумеется, список проблем, которые решают (успешно, на практике) ORM у автора далеко не полон. Вот только наиболее очевидные для меня:
Лично мне прочувствовать пользу ORM на практике помогло написание нескольких небольших проектов на Python без ORM. Начав писать свой абстрактный уровень поверх MySQLdb, я понял, что занимаюсь ерундой. Сравнивая Django ORM, SQLAlchemy или PonyORM с тогдашними моими экзерсисами, я понимаю, что ORM − не кошмар и не гиря на ноге, а реальные помощники в работе, пусть и не идеальные.
А вы точно знаете, что значит это слово?
А старый или не старый − это в данном случае неважно. Главное, чтобы собирал си-расширения.
Конечно, конечно. Мне однажды было надо, я пару дней убил − не разобрался. Потом поставил mingw64 и сделал всё, что надо было, без разбирательств.
Потому что прыгать по сцене и кричать “Developers! Developers!” мы можем, а сделать систему удобной для разработчика − «У вас далеко не типичная задача, пройдите нахер, товарищ!»
Хотя я не думаю, что набор CLI-средств разработки на самом деле должен весить гигабайты, в других системах всё на 2-3 порядка скромнее. Но тут Microsoft виднее, конечно.