Комментарии 32
Я считаю, что лучше избегать преждевременного разделения. Если кодовая база содержит, скажем, 1/2 миллиона строк кода, то настройка связующего слоя (вроде вызовов API) создаст для здравомыслящих разработчиков только лишние хлопоты.
Чем он там занят, если полмиллиона строк на питоне для него – небольшой проект, в котором нет смысла париться со структурой?
Linux 2.0 – 700 000 строк на Си.
Ruff не заменяет mypy и далеко не полностью заменяет pylint, так что есть смысл добавить в pre commit hooks и их.
А что он там компилирует на питоныче? Или ошибка перевода?
В чём вопрос? Python код обычно компилируется в IL перед исполнением. Что в случае CPython, что в случае IronPython и PyPy. Даже если неискушённому глазу это не особо заметно.
На то есть встроенная функция compile() и разбросанные в разных местах .pyc файлы с байткодом
Чем Python в этом плане отличается от Java/C# ?
Разработчики Python проделали старательную работу, скрыв его легаси-уродство (например, __init__, __new__ и аналогичные искажения)
Какая-то глупость. Это не легаси и не искажения, а фундаментальная часть дизайна языка.
А мне Python подходит если что-то мелкое по объему кода и не требовательное к вычислительным ресурсам (навроде одноразика). Как только объем кода повышается, то начиная с некоторого момента времени его вид становится ужасным и трудно поддерживаемым, а в классах бесит мельтешащий self.
а в классах бесит мельтешащий self.
Кмк в каждом языке есть что-то что бесит. Смиритесь, или пилите свой ЯП =)
в классах бесит мельтешащий self
Это чтобы сделать явным, что вы используете или меняете состояние объекта, а не работаете с локальной переменной. Заодно видно, что это не чистая функция.
И с какого объёма кода на питон он становится ужасный?
Видимо, когда приходится повторно перечитать свой же код или когда становится больше одного разработчика. То есть, на проектах small+
Это чтобы сделать явным, что вы используете или меняете состояние объекта, а не работаете с локальной переменной. Заодно видно, что это не чистая функция.
ИМХО, при хорошем именовании, в этом нет необходимости. Только при записи атрибута в self есть необходимость. Если есть одноимённая локальная переменная, то это скорее проблема с именованием. Это и с self может вызвать путаницу. Аналогично с функцией - если её название больше похоже на состояние объекта, чем на действие, то оно, скорее всего, неудачное.
С какого объёма - не знаю, это чисто субъективная оценка.
Знакомство с питоном для здравомыслящего человека заканчивается в момент выбора пакетного менеджера.
Какое-то странное суждение. Я спокойно пользуюсь и pip, и pipx, и poetry. Вообще без разницы. И с ума не сошёл.
Там вроде еще систем сборки 3 десятка, мне страшно читать в ту сторону
Мне вообще странно, почему очень общая задача управления пакетами и структурой зависимостей везде реализуется по-своему?
Кмк, может существовать ОДНА система пакетов, и ее должно быть достаточно для 99% случаев (по правилу Парето). И для Debian и для CentOS и для Python и для Golang и для JavaScript. Для установки пакета могут использоваться разные правила, в пайтоне одни, а в дебиане - другие, но сама идея, что если ты хочешь пакет A, то тебе нужен еще пакеты B и С и надо обновить пакет D, сейчас я их все скачаю и для каждого (в нужном порядке) вызову установку - она мне кажется очень простой.
Я вот не понимаю, чем центос так уж принципиально отличается от дебиана-убунты, а пайтон от JS что им нужны совершенно разные системы управления зависимостями.
В принципе, "Python" в названии можно заменить на любой другой язык или технологию. Нужно просто выбрать оптимальный инструмент под решаемые задачи и тогда вы вряд ли о нем пожалеете.
Странно что обходится вопрос наличия для Python серверов приложений. Возьмите ту же Java - там прямо в архитектуре заложен маштабируемый сервер приложений. И когда работаешь с java понимаешь что все наработанное можно маштабировать, использовать многопоточность и т.д..
А вот у Python мы имеем WSGI спецификацию, которая позволяет исполнять его на веб серверах. Top 6 Open Source Python Application Servers . Это конечно плюс, но Web сервер это еще не application server.
У подозрение, что лишь простота освоения Python позволила распространится ему в ИИ. Я не понимаю как можно сделать что-то серьезное и маштабируемое, если это не имеет хорошего сервера приложений.
Может сервер приложений - артефакт былых времен? Навскидку, ни Golang, ни Rust не имеют сервера приложений, что не мешает создавать "что-то серьезное и маштабируемое" на них.
P.S. к слову, за сервер приложений сейчас выступает docker (и k8s). Так что "нет сервера приложений" - очень спорно. Он просто видоизменился и стал универсальным.
Масштабируемость в Пайтоне достижима, разные варианты, мы можем говорить только о проблеме "чтоб искаропки".
Но как часто ваши проекты доходят до требования масштабируемости? Мне кажется, мир странным образом поделился на две половины.
Есть мир "больших мальчиков", от Гугла-Амазона-Нетфликса до какого-нибудь ПФР и Россельхозбанка (и то я не уверен, что он сюда подходит). В общем, крупные фирмы, большие объемы данных, большие задачи, много серверов итд. Там где каждая задача настолько большая и сложная, что нельзя просто на одном сервере все запустить и чтоб он вытянул. И этих мальчиков - можно перечесть по пальцам (ну ок, потребуется 150-200 пальцев на всю планету, ну для математика это не проблема).
Есть мир "маленьких мальчиков", там каждая задача может выполняться одним сервером. Банк-клиент для физлиц? Окей, вот один сервер под это. Банк-клиент для юрлиц? Окей, вот другой. Отдельно API для платежей, и все такое. Интернет-магазин? Ну кидайте всю статику на что-то одно (от nginx / S3 / CDN) а приложение пусть обрабатывает только покупки. У вас точно настолько успешных бизнес, что происходят сотни покупок в секунду?
Есть еще промежуточная категория. Например, у нас по одному проекту серваку иногда памяти не хватает и он в OOM падает. Но мое мнение - это не "ух ты, какие у нас мощные программисты, какую сложную задачу делают!", а наоборот - остолопы не умеют писать эффективный код, поэтому там, где можно, например, сделать PDFку из кода (хватит 80286 и 1 мегабайта памяти) - запускают headless Chromium, рендерят в нем HTMLку и сохраняют как PDF.
Я даже для одного проекта гонял тесты.... База данных вся в памяти на 1млн записей (будто бы ассортимент крупного магазина). Запросы идут по сложным критериям (смартфон, ценой ниже 500 долларов, но экран не такого-то типа и объем памяти от такого-то. Но если бренд Apple - то можно и ценой до 1500 долларов) и тупо поиск в памяти Python через evalidate - всего четверть секунды! Это самым грубым перебором всех миллионов записей, и применение фильтра к каждой. И эта задача, кстати, легко масштабируется. Но как часто задачи настолько масштабны? А что если у среднего онлайн-магазина - не миллион, а всего тысяча позиций, и покупок - не несколько в секунду, а три в день?
Так вот ирония в том, что большинство звезд индустрии - работают в этих гигантах. Большинство инструментов создаются этими гигантами. Даже большинство "домашних" хобби-проектов когда вырастают до какого-то объема (такого, что Боинг начинает их использовать) - получают затем грант на развитие от Боинга, с его боинговскими пожеланиями, мол, у вас прекрасный продукт для проекта мощностью в 10 единиц, доработайте его чтобы он подходил нам, у нас мощность 200 000 единиц.
Мы живем в мире, где 90% ITшников имеют маленькие задачки, лепят куличики из песочка. Но единственный экскаватор, который они могут использовать - это огромный карьерный экскаватор, а самый популярный грузовичок, чтобы возить песочек - это карьерный БелАЗ на 400 тонн. И в целом-то хорошо, что ты можешь перевезти ведерочка песка, но если потребуется - то и 400 тонн можно. Плохо - что у этого есть какая-то цена. И каждый раз пока ты автоматизируешь зоомагазин на углу - ты зачем-то платишь за ту сложность, которая позволит этому зоомагазину успешно масштабироваться завтра до масштаба Амазона и Нетфликса, кубернетесы развернуть на миллион нод, чтоб аж дата-центр трещал, но этого не случится, а затраты не вернутся.
Не так страшна проблема, что IT-технологии недостаточно масштабируются, как то, что они излишне хорошо масштабируются.
Ну укладывание в один сервер это уже для среднего бизнеса непросто. Вот примеры докладов на Infostart events В сообществе 1С выборы. Сегодня последний день. | 1CUnlimited | Дзен там базы от 9 до 35 терабайт. И это 1С, который конечно как кластер маштабируется, но на уровне СУБД 1 база - один инстанс СУБД. Т.е. ни шардинга ни других средств маштабирования на уровне СУБД нет. И эти примеры не единственные, вот недавно 1С тестировала 30 тыс коннектов Фирма «1С» успешно провела нагрузочное тестирование «1С:ERP Управление предприятием» на 30 000 одновременно работающих пользователей . Это не такой уж и большой по современным маштабам объем, но посмотрите на оборудование особенно в СУБД
"Решил перейти на Python" - с какого языка? Перейти можно с одного на другой.
"к продакшэну" ? Перейдите на русский, тоже не пожалеете.
Решил перейти на Python и не пожалел