История изменений

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

Три персонажа, у которых стул плавится под седалищем от отступов, точно не разрабатывали. Но я уже даже не хочу комментировать, ибо там хоть кол на голове теши. Ещё и придумали какие-то метрики, типа того, что 10-15% времени тратится на отступы. Фейспалм. Но ладно, тут только галоперидол может помочь.

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

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

Статическая типизация помогает, но от балды скажу, что наверное 95% больших кодовых баз ещё не типизированы, и, возможно, никогда не будут.

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

Ещё одна проблема: запутанная система импортов. Надо понимать, что Python начинался очень давно, и система импортов и пакаджей навешивалась сверху, путем подстановки костыликов под различные юзкейсы (например, namespace packages). Из-за этого, бывает, что приходится поломать голову, как структурировать свой пакет или библиотеку, или почему что-то не импортируется. Но это скорее джуно-миддловская проблема, т.к. всё формализовано, и если раз и навсегда запомнить правила импортирования, то сюрпризы быстро разрешаются.

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

Четвёртая боль: Python медленный. Это имеет значение гораздо реже, чем считают многие, но иногда всё-таки имеет значение.

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

Три персонажа, у которых стул плавится под седалищем от отступов, точно не разрабатывали. Но я уже даже не хочу комментировать, ибо там хоть кол на голове теши. Ещё и придумали какие-то метрики, типа того, что 10-15% времени тратится на отступы. Фейспалм. Но ладно, тут только галоперидол может помочь.

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

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

Статическая типизация помогает, но от балды скажу, что наверное 95% больших кодовых баз ещё не типизированы, и, возможно, никогда не будут.

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

Ещё одна проблема: запутанная система импортов. Надо понимать, что Python начинался очень давно, и система импортов и пакаджей навешивалась сверху, путем подстановки костыликов под различные юзкейсы (например, namespace packages). Из-за этого, бывает, что приходится поломать голову, как структурировать свой пакет или библиотеку, или почему что-то не импортируется. Но это скорее джуно-миддловская проблема, т.к. всё формализовано, и если раз и навсегда запомнить правила импортирования, то сюрпризы быстро разрешаются.

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

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

Три персонажа, у которых стул плавится под седалищем от отступов, точно не разрабатывали. Но я уже даже не хочу комментировать, ибо там хоть кол на голове теши. Ещё и придумали какие-то метрики, типа того, что 10-15% времени тратится на отсупы. Фейспалм. Но ладно, тут только галоперидол может помочь.

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

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

Статическая типизация помогает, но от балды скажу, что наверное 95% больших кодовых баз ещё не типизированы, и, возможно, никогда не будут.

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

Ещё одна проблема: запутанная система импортов. Надо понимать, что Python начинался очень давно, и система импортов и пакаджей навешивалась сверху, путем подстановки костыликов под различные юзкейсы (например, namespace packages). Из-за этого, бывает, что приходится поломать голову, как структурировать свой пакет или библиотеку, или почему что-то не импортируется. Но это скорее джуно-миддловская проблема, т.к. всё формализовано, и если раз и навсегда запомнить правила импортирования, то сюрпризы быстро разрешаются.

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