@MBode4 апр 2019 в 11:31

Python для Веба: что нужно знать джуниору, чтобы работать и развиваться

7 мин

163K

Python * ИнтервьюКарьера в IT-индустрииУчебный процесс в IT

+13

Комментарии 40

@neochapay 4 апр 2019 в 12:35

Глядя на КДПВ сразу подумалось…

@Corpsee 4 апр 2019 в 12:44

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

@peresada 5 апр 2019 в 04:23

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

@fso 4 апр 2019 в 13:21

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

@LighteR 4 апр 2019 в 15:39

Отсутствие констант

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

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

Все прекрасно обходятся без них

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

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

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

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

И по производительности и по «заточенности»

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

@fso 4 апр 2019 в 16:08

Не особо нужно

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

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

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

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

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

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

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

@mamokino 4 апр 2019 в 16:14

Большинство вещей, которые делаются в PHP на базовом уровне, в питоне делает фреймворк

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

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

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

@fso 4 апр 2019 в 16:20

Соглашусь с вами, не утверждал что это большая проблема, просто обратил внимание, что php проектировался именно под веб, когда как для питона web — не родная среда.

@mamokino 4 апр 2019 в 16:27

что php проектировался именно под веб

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

@worldmind 4 апр 2019 в 17:22

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

попобробнее, какую проблему имеете ввиду и как она что-то диктует

@LighteR 5 апр 2019 в 00:12

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

Большинство этих зрелых языков, в которых есть константы являются статически типизированными и проверка на переопределение констант происходит на этапе компиляции, что значительно лучше чем проверка в рантайме. Вот 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 — это не целевая задача питона и делается сравнительно «сторонними» от ядра, средствами.

И что в этом плохого? Как это мешает разработчику?

@007913 5 апр 2019 в 03:33

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

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

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

@worldmind 4 апр 2019 в 17:15

Отсутствие констант

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

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

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

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

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

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

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

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

видимо такого же уровня

@fso 4 апр 2019 в 17:38

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

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

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

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

@worldmind 4 апр 2019 в 17:54

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

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

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

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

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

@fso 4 апр 2019 в 20:18

Или что-то другое имеете ввиду?

Да, чуть ошибся, я имел ввиду контекст protected. То есть при наследовании доступен, но недоступен при вызове снаружи. И не сокрытие видимости с помощью __ (кстати, тоже не выглядит элегантным), а именно ограничение доступа.

@worldmind 5 апр 2019 в 06:05

Дело в то, что за этим стоит базовые концепции языка, философия его создателей, вы её можете не разделять, но понимать стоит, об этом много написано, например тут, суть в том, что авторы питона считают (и я с ними согласен), что если программист дурак или вредитель, то никакими техническими ухищрениями вы не сделаете его умным и не защититись от его попыток навредить.
А нормальный человек если видит _some_method понимает, что это protected или __some_method — private и знает что на них полагаться нельзя.
Более того, на самом деле никто не знает как и почему, кому-то может понабодиться использовать ваш protected метод, пусть человек, под свою ответственность принимает решение в конкретном случае, ведь мы же считаем, что он понимает что делает.
Но если у вас нет нормальных программистов, то можно поискать решение, в питоне можно сделать практически всё, вот например попалось или вот, но не тестил.

@fso 5 апр 2019 в 07:37

А зачем, если можно взять язык, в котором это все просто-напросто есть?

@worldmind 5 апр 2019 в 07:41

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

@fso 5 апр 2019 в 07:44

Трудно не согласиться с этим) Но мы как-то уклонилсь от изначального посыла в обсуждении «заточенности» питона под веб, перейдя к его недостаткам. Конечно, нет серебряной пули, у всего есть свои плюсы и минусы. Но, ИМХО, питон мог бы стать много лучше, причем малой кровью.

@worldmind 5 апр 2019 в 07:52

Во-первых, не все решения так просты, попробуйте предложить куда-нибудь в python-ideas и скорее всего выяснится, что не так уж просто.
Во-вторых, он и становится лучше, с каждой версией, медленно, но верно. Оснований для спешки нет, те кто делают быстрее обычно делают плохо и на длинной дистации отваливаются.

@fso 5 апр 2019 в 07:56

3-ей версии питона уже 11 лет… и первый мой комментарий как раз и был про то, что «не все так просто» и это во многом мешает питону развиваться, по крайней мере в сторону веба.

@worldmind 5 апр 2019 в 08:00

И? А Python 3.7.3 вышел 10 дней назад.

@fso 5 апр 2019 в 08:17

Не думаю, что такие вещи с которыми «не все просто» можно выпустить в минорных версиях. Вы смотрели changelog 3.7.3? Там только фиксы, только работа над ошибками, залатывание багов. Медленно очень.

@LighteR 4 апр 2019 в 21:39

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

Можете привести пример такого кода в вашем проекте?

@fso 4 апр 2019 в 21:49

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

SETTINGS_CONSTANT = 1

condition = SETTINGS_CONSTANT = 2 # Must be == 2

if condition:
    print("Now SETTINGS_CONSTANT=%s" % SETTINGS_CONSTANT)

@fso 4 апр 2019 в 17:49

а это реализуется кучей способов

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

@worldmind 4 апр 2019 в 17:55

Да не надо обходится, берёте namedtuple и получаете иммутабельную структуру данных с красивым синтаксисом доступа (dot notation).

@fso 4 апр 2019 в 19:21

Вы не хотите меня понять) Я не говорю что в питоне нельзя сделать неизменяемую структуру. я говорю, что это делается не как в других языках, специальным для этого инструментом — константой, а обходными путями, namedtuple в частности, занулением сеттеров и прочими костылями.

@worldmind 5 апр 2019 в 05:43

Ну да, у каждого языка есть какие-то особенности, но если возможность есть, то на значимый недостаток это не тянет, хотя согласен что это минус.

@mamokino 4 апр 2019 в 15:46

Давайте рассмотрим возможные варианты.

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

@mkshma 4 апр 2019 в 16:18

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

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

@mamokino 4 апр 2019 в 16:22

Поигрались и потихоньку бросают в пользу более полноценных языков.

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

Какие именно, «более полноценные» для высоконагруженных решений?

@worldmind 4 апр 2019 в 17:18

Не тестил, но не раз слышал, что нормальные питонные фреймворки с uvloop под капотом дают такую же производительность как го и нода, вот например.

@mamokino 5 апр 2019 в 18:26

такую же производительность как го и нода

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

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

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

И все это, замечу, без каких-либо ухищрений как с CPython, а штатным компилятором.

@worldmind 8 апр 2019 в 07:45

А что вы называете ухищрениями?

НЛО прилетело и опубликовало эту надпись здесь

@dididididi 5 апр 2019 в 08:38

Сооснователь, евангелист и преподаватель))
А программистов-питонщиков про питон нельзя было спросить, обязательно людей с какими то странными регалиями?
Надо себе тоже чонить придумать, типа «Джаваокий ангел Дмитрий».

@Terras 7 апр 2019 в 22:17

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

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

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

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

@Singaporian 9 июл 2019 в 19:51

Что входит в базис для веб-разработки на Python

...

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

...

Ебобо вообще?

Зарегистрируйтесь на Хабре, чтобы оставить комментарий