Pull to refresh

Comments 40

Ответ на вопрос «Почему именно Python подходит для веб-разработки?» — какой-то бред от начала и до конца. В вебе нет альтернатив Python-у, а Ruby — нишевый, как Haskell… Ну и по остальному списку языков какой-то адский треш.
В частности позабавило про ПХП, мол он замечательный и не уступает питону, но не стоит его использовать, потому что языку уже ХХ лет и везде куча легаси
Питон довольно сильно застрял в своей парадигме и это мешает ему развиваться в нужном для веб направлении. Отсутствие констант, модификаторов доступа, длинные простыни кода в одиночных файлах, мутная история с тайпхинтингом/типизацией и многое другое. Питон хорош для научной работы, математики, расчетов, числодробилок наконец. В вебе он как-то держится, но тот же PHP 7-ых версий именно в вебе, будет наголову выше. И по производительности и по «заточенности».
Отсутствие констант

Не особо нужно, но оно есть в виде тайпхинта: mypy.readthedocs.io/en/latest/final_attrs.html
модификаторов доступа

Все прекрасно обходятся без них
длинные простыни кода в одиночных файлах

Какое это имеет отношение к ЯП. В других языках нельзя что ли простыню сделать?
мутная история с тайпхинтингом/типизацией

В чем ее мутность? В Python нормальная система типов, в отличии от велосипеда с квадратными колесами в PHP7
И по производительности и по «заточенности»

В чем заточенность? В том что у php даже event loop'а из коробки нет?
Не особо нужно

Да, обойтись можно без чего угодно. Однако практика показывает, что во всех зрелых языках они есть, ибо есть задачи которые константы решают. Если нет констант — нет для этих задач предназначенного инструмента.

В других языках нельзя что ли простыню сделать?

Речь про то, что питон диктует так делать (проблема циклического импорта) и устоявшаяся практика. Посмотрите на models.py в django любого сложного проекта.

В чем ее мутность?

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

В чем заточенность?

PHP изначально проектировался для обработки http запросов, цикл обработки запроса заточен именно под это. Как пример — встроенный механизм сессий. работа с сессиями — это функции самого языка.
Большинство вещей, которые делаются в PHP на базовом уровне, в питоне делает фреймворк. И оно понятно, обработка http — это не целевая задача питона и делается сравнительно «сторонними» от ядра, средствами.
Большинство вещей, которые делаются в PHP на базовом уровне, в питоне делает фреймворк


Вы это пишете в то время, когда полным-полно для Python'а качественных фреймворков и/или библиотек для веба. И когда существует удобное управление пакетами для установки/обновления этих фреймворков/библиотек.

Сейчас уже наличие/отсутствие функционала «под веб» непосредственно в стандартной библиотеке Python'а проблемой не является.

Про PHP можно сказать ровно тоже самое. Без PHP-расширений (тех, что бинарные, написанные обычно на С) — сделать полнофункциональный сколько-нибудь сложный сайт невозможно.
Соглашусь с вами, не утверждал что это большая проблема, просто обратил внимание, что php проектировался именно под веб, когда как для питона web — не родная среда.
что php проектировался именно под веб

Только шаблонизатор у PHP самая сильная сторона в его «заточенности на веб».
А вот остальное — вполне себе имеет хорошие решения и в других языках.

Речь про то, что питон диктует так делать (проблема циклического импорта)

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

Большинство этих зрелых языков, в которых есть константы являются статически типизированными и проверка на переопределение констант происходит на этапе компиляции, что значительно лучше чем проверка в рантайме. Вот Final, который я кидал выше способ сделать константу проверяемую на этапе статического анализа. Ну и получается что Lua и Ruby недостаточно зрелые?
И в том, что при запуске и в рантайме, питон не пикнет даже если будут несоответствие типов (частая проблема при использовании сторонних пакетов, где pypy не поможет ввиду отсутствия тайпхинтинга в этих самых сторонних пакетах ).

Да, пока далеко не во всех библиотеках есть тайпхинты. Но это же не проблема системы типов питона. Со временем тайпхинты будут появляться все в большем кол-ве библиотек. В любом случае ставить тайпхинты в минус питону, когда в php все гораздо примитивнее и вообще не позволяет делать хоть какой-то вразумительный статический анализ, довольно странно.
Речь про то, что питон диктует так делать (проблема циклического импорта) и устоявшаяся практика. Посмотрите на models.py в django любого сложного проекта.

Мне кажется, вы преувеличиваете проблему циклических импортов. Почти во всех проектах на django, которые я видел models был разбит на packages/modules
В необходимости писать тип в виде строки вместо непосредственно литерала, если импортировать тип нельзя из-за проблемы циклического импорта.

Опять же, проблема, мне кажется немного преувеличенной, но тем не менее начиная с Python 3.7 это уже не проблема: www.python.org/dev/peps/pep-0563
Большинство вещей, которые делаются в PHP на базовом уровне, в питоне делает фреймворк.

Для каких-то вещей это даже хорошо. Как правило release cycle языка сильно длиннее чем у библиотеки/фреймворка, что позволяет добавлять новые фичи/фиксить баги гораздо оперативнее не дожидаясь релиза новой версии языка.
И оно понятно, обработка http — это не целевая задача питона и делается сравнительно «сторонними» от ядра, средствами.

И что в этом плохого? Как это мешает разработчику?
Я бы не согласился насчет «Простыни кода» и что все вынуждают пихать в один файл. В том то и сила питона — в его «гибкости», ты можешь многое регулировать в том как интерпретатор будет работать с твоими скриптами, да быть может это порой порушит читаемость (местами) но далеко не всегда, причем профит от структурированности перевешивает небольшую потерю понятности. Я у себя в некоторых частях программы сделал хранение определений классов моделек в чтоли java-подобном стиле (Основной тематический класс в одноименном классу файле) а так как «питон гибок» всего-то поправил __init__ пакета чтобы конструкции импорта которые уже юзали сохранили обратную совместимость при различных конструкциях импорта.

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

А насчет констант как сущности — согласен это было бы полезно, еще бы круто если бы они были типа «в общем пуле сессии интерпретатора» и не зависели от импорта в конкретном модуле, кстати этот момент тоже в современных питонах кажется разрулили или разруливают :)
Отсутствие констант


Константы нужны только для неизменяемых конфигурационных данных, а это реализуется кучей способов, от юзания стандартных namedtuple, до юзания frozen box.

модификаторов доступа

если вы про всякие public/private, то в питоне всё это есть, пусть и немного по иному реализованное, хотя по факту ценность этих вещей преувеличена

длинные простыни кода в одиночных файлах

это какой-то бред не связанный с питоном

мутная история с тайпхинтингом/типизацией

если не пытаться разобраться, то всё будет мутно, а по факту всё более чем хорошо и юзаетсчя в продакшене

и многое другое

видимо такого же уровня
Веду сейчас крупный федеральный проект на питоне, с большой распределенной командой разработчиков. Проблемы на самом деле существуют.

Отсутствие констант очень сильно мешает, особенно в легаси 2.7 версии. Доходит до того, что простая опечатка в сравнении приводит к изменению значения того, что меняться в принципе не должно.

Невозможность приватных методов приводит к тому, что один разработчик начинает использовать публично метод, который для этого не предназначался и при дальнейшей разработке будет меняться несовместимо. Понятно что все это культура программистов, но предпосылки этих проблем — отсутствие модификаторов доступа.

Большая простыня models.py приводит к конфликтам слияния, попытка разбить на модули — к проблеме циклического импорта. И так далее.
Ну те кто используют 2 питон жаловаться права не имеют, так можно и на дористорический пхп жаловаться, да вообще на все старые версии языков.
Про константы я сказал, решения есть в том числе в стандартной библиотеке, кому нужно, тот использует.

Невозможность приватных методов

Вы ведёте проект и не владеете языком? Или что-то другое имеете ввиду?
В питоне есть достаточно приватные методы, погуглите чтоль про python private method да про property.

попытка разбить на модули — к проблеме циклического импорта.

Я пока не понимаю о чём вы, погуглите python avoid cyclic import
Или что-то другое имеете ввиду?

Да, чуть ошибся, я имел ввиду контекст protected. То есть при наследовании доступен, но недоступен при вызове снаружи. И не сокрытие видимости с помощью __ (кстати, тоже не выглядит элегантным), а именно ограничение доступа.
Дело в то, что за этим стоит базовые концепции языка, философия его создателей, вы её можете не разделять, но понимать стоит, об этом много написано, например тут, суть в том, что авторы питона считают (и я с ними согласен), что если программист дурак или вредитель, то никакими техническими ухищрениями вы не сделаете его умным и не защититись от его попыток навредить.
А нормальный человек если видит _some_method понимает, что это protected или __some_method — private и знает что на них полагаться нельзя.
Более того, на самом деле никто не знает как и почему, кому-то может понабодиться использовать ваш protected метод, пусть человек, под свою ответственность принимает решение в конкретном случае, ведь мы же считаем, что он понимает что делает.
Но если у вас нет нормальных программистов, то можно поискать решение, в питоне можно сделать практически всё, вот например попалось или вот, но не тестил.
А зачем, если можно взять язык, в котором это все просто-напросто есть?
Каждый выбирает тот инструмент, который считает лучшим по сумме показателей, к счастью тут есть свобода выбора, если вам ближе идеология условно джавы, то не пишите на питоне.
Трудно не согласиться с этим) Но мы как-то уклонилсь от изначального посыла в обсуждении «заточенности» питона под веб, перейдя к его недостаткам. Конечно, нет серебряной пули, у всего есть свои плюсы и минусы. Но, ИМХО, питон мог бы стать много лучше, причем малой кровью.
Во-первых, не все решения так просты, попробуйте предложить куда-нибудь в python-ideas и скорее всего выяснится, что не так уж просто.
Во-вторых, он и становится лучше, с каждой версией, медленно, но верно. Оснований для спешки нет, те кто делают быстрее обычно делают плохо и на длинной дистации отваливаются.
3-ей версии питона уже 11 лет… и первый мой комментарий как раз и был про то, что «не все так просто» и это во многом мешает питону развиваться, по крайней мере в сторону веба.
И? А Python 3.7.3 вышел 10 дней назад.
Не думаю, что такие вещи с которыми «не все просто» можно выпустить в минорных версиях. Вы смотрели changelog 3.7.3? Там только фиксы, только работа над ошибками, залатывание багов. Медленно очень.
Отсутствие констант очень сильно мешает, особенно в легаси 2.7 версии. Доходит до того, что простая опечатка в сравнении приводит к изменению значения того, что меняться в принципе не должно.

Можете привести пример такого кода в вашем проекте?
Примерно такое было (django с его настройками в settings.py в виде «констант»):

SETTINGS_CONSTANT = 1

condition = SETTINGS_CONSTANT = 2 # Must be == 2

if condition:
    print("Now SETTINGS_CONSTANT=%s" % SETTINGS_CONSTANT)
а это реализуется кучей способов

Фактически, я и хотел сказать, что не надо «кучу способов», нужны просто константы. Зачем эти обходные пути, костыли-велосипеды, когда, повторюсь, во всех зрелых языках просто есть константы. И просто есть модификаторы доступа. И да, без них можно обойтись, но они придуманы не просто так и решают вполне насущные проблемы.
Да не надо обходится, берёте namedtuple и получаете иммутабельную структуру данных с красивым синтаксисом доступа (dot notation).
Вы не хотите меня понять) Я не говорю что в питоне нельзя сделать неизменяемую структуру. я говорю, что это делается не как в других языках, специальным для этого инструментом — константой, а обходными путями, namedtuple в частности, занулением сеттеров и прочими костылями.
Ну да, у каждого языка есть какие-то особенности, но если возможность есть, то на значимый недостаток это не тянет, хотя согласен что это минус.
Давайте рассмотрим возможные варианты.

  • C#
  • Java
  • PHP
  • JavaScript и Node.js


JavaScript сейчас имеет смысл рассматривать сразу с TypeScript, а не опционально.

Go забыли. А он имеет в вебе довольно сильные позиции. Да и разрабатывался с учетом веб-применения.

Ruby. Никакой он не нишевой как написано в статье, а вполне себе с кучей инструментария именно что и под web. Тоже вполне можно отнести к основным веб-языкам.

Под спойлером те, что нельзя причислить к основным веб-языкам, но, все же используемые в вебе
Следующие мало где пока используются в вебе, но все же уже не экзотика для веба:

Elixir
Kotlin
Dart

Еще экзотика для веба, но все же используемая иногда:

Clojure
Erlang
Rust

У Юли пообъективнее про выбор языка в 2019 году
Imagine you have to select a programming language in 2019
Go забыли. А он имеет в вебе довольно сильные позиции. Да и разрабатывался с учетом веб-применения.

Go — это Ruby 2016-2018х годов. Поигрались и потихоньку бросают в пользу более полноценных языков.
Поигрались и потихоньку бросают в пользу более полноценных языков.


Кто именно бросает?
Для высоконагруженных решений альтернатив мало.

Какие именно, «более полноценные» для высоконагруженных решений?
Не тестил, но не раз слышал, что нормальные питонные фреймворки с uvloop под капотом дают такую же производительность как го и нода, вот например.
такую же производительность как го и нода

Говоря про производительность вы напрасно поставили рядом Go и Node.JS.

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

По поводу «особо быстрого Python», если уж применяются спец-решения с Python, как CPython в вашей ссылке, то, полагаю, будет справедливо рассматривать и спец-решения для Go, например, fasthttp, который существенно быстрее встроенного в Go пакета http github.com/smallnest/go-web-framework-benchmark

И все это, замечу, без каких-либо ухищрений как с CPython, а штатным компилятором.
А что вы называете ухищрениями?
UFO landed and left these words here
Сооснователь, евангелист и преподаватель))
А программистов-питонщиков про питон нельзя было спросить, обязательно людей с какими то странными регалиями?
Надо себе тоже чонить придумать, типа «Джаваокий ангел Дмитрий».
Если честно реальность такова, что питон хорош по-большей части в проектах, где требуется какой-то расчет, математические модели и прочие штуки, связанные с работой с данными. Это объясняется наличием крутых математических и машин-лернинг библиотек.

Для всего остального — выбор питона это откровенная вкусовщина, которая ничем не объясняется, кроме как «Мы выбрали питон, так как нам нравился питон».

Django — убер удобный фреймворк для целого набора вещей. Тут вопросов нет.

Flask/Tornado/Twisted/aiohtp — уже неудобней и запутанней. И уже появляется вопрос, а нужно ли нам это все, и не взять ли что-то более «стандартное» для этого.
Что входит в базис для веб-разработки на Python

  • ...
  • Протоколы и API: в первую очередь http, JSON-RPC, Protocol Buffers, gRPC.
  • ...

Ебобо вообще?
Only those users with full accounts are able to leave comments. Log in, please.

Please pay attention