Comments 40
Глядя на КДПВ сразу подумалось…
+8
Ответ на вопрос «Почему именно Python подходит для веб-разработки?» — какой-то бред от начала и до конца. В вебе нет альтернатив Python-у, а Ruby — нишевый, как Haskell… Ну и по остальному списку языков какой-то адский треш.
+5
Питон довольно сильно застрял в своей парадигме и это мешает ему развиваться в нужном для веб направлении. Отсутствие констант, модификаторов доступа, длинные простыни кода в одиночных файлах, мутная история с тайпхинтингом/типизацией и многое другое. Питон хорош для научной работы, математики, расчетов, числодробилок наконец. В вебе он как-то держится, но тот же PHP 7-ых версий именно в вебе, будет наголову выше. И по производительности и по «заточенности».
+6
Отсутствие констант
Не особо нужно, но оно есть в виде тайпхинта: mypy.readthedocs.io/en/latest/final_attrs.html
модификаторов доступа
Все прекрасно обходятся без них
длинные простыни кода в одиночных файлах
Какое это имеет отношение к ЯП. В других языках нельзя что ли простыню сделать?
мутная история с тайпхинтингом/типизацией
В чем ее мутность? В Python нормальная система типов, в отличии от велосипеда с квадратными колесами в PHP7
И по производительности и по «заточенности»
В чем заточенность? В том что у php даже event loop'а из коробки нет?
0
Не особо нужно
Да, обойтись можно без чего угодно. Однако практика показывает, что во всех зрелых языках они есть, ибо есть задачи которые константы решают. Если нет констант — нет для этих задач предназначенного инструмента.
В других языках нельзя что ли простыню сделать?
Речь про то, что питон диктует так делать (проблема циклического импорта) и устоявшаяся практика. Посмотрите на models.py в django любого сложного проекта.
В чем ее мутность?
В необходимости писать тип в виде строки вместо непосредственно литерала, если импортировать тип нельзя из-за проблемы циклического импорта. И в том, что при запуске и в рантайме, питон не пикнет даже если будут несоответствие типов (частая проблема при использовании сторонних пакетов, где pypy не поможет ввиду отсутствия тайпхинтинга в этих самых сторонних пакетах ).
В чем заточенность?
PHP изначально проектировался для обработки http запросов, цикл обработки запроса заточен именно под это. Как пример — встроенный механизм сессий. работа с сессиями — это функции самого языка.
Большинство вещей, которые делаются в PHP на базовом уровне, в питоне делает фреймворк. И оно понятно, обработка http — это не целевая задача питона и делается сравнительно «сторонними» от ядра, средствами.
+1
Большинство вещей, которые делаются в PHP на базовом уровне, в питоне делает фреймворк
Вы это пишете в то время, когда полным-полно для Python'а качественных фреймворков и/или библиотек для веба. И когда существует удобное управление пакетами для установки/обновления этих фреймворков/библиотек.
Сейчас уже наличие/отсутствие функционала «под веб» непосредственно в стандартной библиотеке Python'а проблемой не является.
Про PHP можно сказать ровно тоже самое. Без PHP-расширений (тех, что бинарные, написанные обычно на С) — сделать полнофункциональный сколько-нибудь сложный сайт невозможно.
0
Соглашусь с вами, не утверждал что это большая проблема, просто обратил внимание, что php проектировался именно под веб, когда как для питона web — не родная среда.
0
Речь про то, что питон диктует так делать (проблема циклического импорта)
попобробнее, какую проблему имеете ввиду и как она что-то диктует
0
Да, обойтись можно без чего угодно. Однако практика показывает, что во всех зрелых языках они есть, ибо есть задачи которые константы решают. Если нет констант — нет для этих задач предназначенного инструмента.
Большинство этих зрелых языков, в которых есть константы являются статически типизированными и проверка на переопределение констант происходит на этапе компиляции, что значительно лучше чем проверка в рантайме. Вот 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 — это не целевая задача питона и делается сравнительно «сторонними» от ядра, средствами.
И что в этом плохого? Как это мешает разработчику?
0
Я бы не согласился насчет «Простыни кода» и что все вынуждают пихать в один файл. В том то и сила питона — в его «гибкости», ты можешь многое регулировать в том как интерпретатор будет работать с твоими скриптами, да быть может это порой порушит читаемость (местами) но далеко не всегда, причем профит от структурированности перевешивает небольшую потерю понятности. Я у себя в некоторых частях программы сделал хранение определений классов моделек в чтоли java-подобном стиле (Основной тематический класс в одноименном классу файле) а так как «питон гибок» всего-то поправил __init__ пакета чтобы конструкции импорта которые уже юзали сохранили обратную совместимость при различных конструкциях импорта.
Циклический импорт, да неудобство, но кажется в последних версиях питона с ним разобрались «из коробки», кроме того ранее частично можно было с ним бороться стратегией типа «каталогов», «регистрированием модулей» через какую-то общую переменную в другом модуле.
А насчет констант как сущности — согласен это было бы полезно, еще бы круто если бы они были типа «в общем пуле сессии интерпретатора» и не зависели от импорта в конкретном модуле, кстати этот момент тоже в современных питонах кажется разрулили или разруливают :)
Циклический импорт, да неудобство, но кажется в последних версиях питона с ним разобрались «из коробки», кроме того ранее частично можно было с ним бороться стратегией типа «каталогов», «регистрированием модулей» через какую-то общую переменную в другом модуле.
А насчет констант как сущности — согласен это было бы полезно, еще бы круто если бы они были типа «в общем пуле сессии интерпретатора» и не зависели от импорта в конкретном модуле, кстати этот момент тоже в современных питонах кажется разрулили или разруливают :)
0
Отсутствие констант
Константы нужны только для неизменяемых конфигурационных данных, а это реализуется кучей способов, от юзания стандартных namedtuple, до юзания frozen box.
модификаторов доступа
если вы про всякие public/private, то в питоне всё это есть, пусть и немного по иному реализованное, хотя по факту ценность этих вещей преувеличена
длинные простыни кода в одиночных файлах
это какой-то бред не связанный с питоном
мутная история с тайпхинтингом/типизацией
если не пытаться разобраться, то всё будет мутно, а по факту всё более чем хорошо и юзаетсчя в продакшене
и многое другое
видимо такого же уровня
-1
Веду сейчас крупный федеральный проект на питоне, с большой распределенной командой разработчиков. Проблемы на самом деле существуют.
Отсутствие констант очень сильно мешает, особенно в легаси 2.7 версии. Доходит до того, что простая опечатка в сравнении приводит к изменению значения того, что меняться в принципе не должно.
Невозможность приватных методов приводит к тому, что один разработчик начинает использовать публично метод, который для этого не предназначался и при дальнейшей разработке будет меняться несовместимо. Понятно что все это культура программистов, но предпосылки этих проблем — отсутствие модификаторов доступа.
Большая простыня models.py приводит к конфликтам слияния, попытка разбить на модули — к проблеме циклического импорта. И так далее.
Отсутствие констант очень сильно мешает, особенно в легаси 2.7 версии. Доходит до того, что простая опечатка в сравнении приводит к изменению значения того, что меняться в принципе не должно.
Невозможность приватных методов приводит к тому, что один разработчик начинает использовать публично метод, который для этого не предназначался и при дальнейшей разработке будет меняться несовместимо. Понятно что все это культура программистов, но предпосылки этих проблем — отсутствие модификаторов доступа.
Большая простыня models.py приводит к конфликтам слияния, попытка разбить на модули — к проблеме циклического импорта. И так далее.
0
Ну те кто используют 2 питон жаловаться права не имеют, так можно и на дористорический пхп жаловаться, да вообще на все старые версии языков.
Про константы я сказал, решения есть в том числе в стандартной библиотеке, кому нужно, тот использует.
Вы ведёте проект и не владеете языком? Или что-то другое имеете ввиду?
В питоне есть достаточно приватные методы, погуглите чтоль про python private method да про property.
Я пока не понимаю о чём вы, погуглите
Про константы я сказал, решения есть в том числе в стандартной библиотеке, кому нужно, тот использует.
Невозможность приватных методов
Вы ведёте проект и не владеете языком? Или что-то другое имеете ввиду?
В питоне есть достаточно приватные методы, погуглите чтоль про python private method да про property.
попытка разбить на модули — к проблеме циклического импорта.
Я пока не понимаю о чём вы, погуглите
python avoid cyclic import
-1
Или что-то другое имеете ввиду?
Да, чуть ошибся, я имел ввиду контекст
protected
. То есть при наследовании доступен, но недоступен при вызове снаружи. И не сокрытие видимости с помощью __
(кстати, тоже не выглядит элегантным), а именно ограничение доступа.0
Дело в то, что за этим стоит базовые концепции языка, философия его создателей, вы её можете не разделять, но понимать стоит, об этом много написано, например тут, суть в том, что авторы питона считают (и я с ними согласен), что если программист дурак или вредитель, то никакими техническими ухищрениями вы не сделаете его умным и не защититись от его попыток навредить.
А нормальный человек если видит
Более того, на самом деле никто не знает как и почему, кому-то может понабодиться использовать ваш protected метод, пусть человек, под свою ответственность принимает решение в конкретном случае, ведь мы же считаем, что он понимает что делает.
Но если у вас нет нормальных программистов, то можно поискать решение, в питоне можно сделать практически всё, вот например попалось или вот, но не тестил.
А нормальный человек если видит
_some_method
понимает, что это protected или __some_method
— private и знает что на них полагаться нельзя.Более того, на самом деле никто не знает как и почему, кому-то может понабодиться использовать ваш protected метод, пусть человек, под свою ответственность принимает решение в конкретном случае, ведь мы же считаем, что он понимает что делает.
Но если у вас нет нормальных программистов, то можно поискать решение, в питоне можно сделать практически всё, вот например попалось или вот, но не тестил.
-1
А зачем, если можно взять язык, в котором это все просто-напросто есть?
0
Каждый выбирает тот инструмент, который считает лучшим по сумме показателей, к счастью тут есть свобода выбора, если вам ближе идеология условно джавы, то не пишите на питоне.
0
Трудно не согласиться с этим) Но мы как-то уклонилсь от изначального посыла в обсуждении «заточенности» питона под веб, перейдя к его недостаткам. Конечно, нет серебряной пули, у всего есть свои плюсы и минусы. Но, ИМХО, питон мог бы стать много лучше, причем малой кровью.
0
Во-первых, не все решения так просты, попробуйте предложить куда-нибудь в python-ideas и скорее всего выяснится, что не так уж просто.
Во-вторых, он и становится лучше, с каждой версией, медленно, но верно. Оснований для спешки нет, те кто делают быстрее обычно делают плохо и на длинной дистации отваливаются.
Во-вторых, он и становится лучше, с каждой версией, медленно, но верно. Оснований для спешки нет, те кто делают быстрее обычно делают плохо и на длинной дистации отваливаются.
0
Отсутствие констант очень сильно мешает, особенно в легаси 2.7 версии. Доходит до того, что простая опечатка в сравнении приводит к изменению значения того, что меняться в принципе не должно.
Можете привести пример такого кода в вашем проекте?
0
а это реализуется кучей способов
Фактически, я и хотел сказать, что не надо «кучу способов», нужны просто константы. Зачем эти обходные пути, костыли-велосипеды, когда, повторюсь, во всех зрелых языках просто есть константы. И просто есть модификаторы доступа. И да, без них можно обойтись, но они придуманы не просто так и решают вполне насущные проблемы.
+1
Да не надо обходится, берёте namedtuple и получаете иммутабельную структуру данных с красивым синтаксисом доступа (dot notation).
-1
Вы не хотите меня понять) Я не говорю что в питоне нельзя сделать неизменяемую структуру. я говорю, что это делается не как в других языках, специальным для этого инструментом — константой, а обходными путями, namedtuple в частности, занулением сеттеров и прочими костылями.
+1
Давайте рассмотрим возможные варианты.
- 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
Elixir
Kotlin
Dart
Еще экзотика для веба, но все же используемая иногда:
Clojure
Erlang
Rust
У Юли пообъективнее про выбор языка в 2019 году
Imagine you have to select a programming language in 2019
+3
Go забыли. А он имеет в вебе довольно сильные позиции. Да и разрабатывался с учетом веб-применения.
Go — это Ruby 2016-2018х годов. Поигрались и потихоньку бросают в пользу более полноценных языков.
-2
Поигрались и потихоньку бросают в пользу более полноценных языков.
Кто именно бросает?
Для высоконагруженных решений альтернатив мало.
Какие именно, «более полноценные» для высоконагруженных решений?
0
такую же производительность как го и нода
Говоря про производительность вы напрасно поставили рядом Go и Node.JS.
Впрочем, не спорю, что на каких-то определенных, как сейчас принято говорить, «кэйсах использования» можно получить близкую производительность.
По поводу «особо быстрого Python», если уж применяются спец-решения с Python, как CPython в вашей ссылке, то, полагаю, будет справедливо рассматривать и спец-решения для Go, например, fasthttp, который существенно быстрее встроенного в Go пакета http github.com/smallnest/go-web-framework-benchmark
И все это, замечу, без каких-либо ухищрений как с CPython, а штатным компилятором.
0
UFO just landed and posted this here
Сооснователь, евангелист и преподаватель))
А программистов-питонщиков про питон нельзя было спросить, обязательно людей с какими то странными регалиями?
Надо себе тоже чонить придумать, типа «Джаваокий ангел Дмитрий».
А программистов-питонщиков про питон нельзя было спросить, обязательно людей с какими то странными регалиями?
Надо себе тоже чонить придумать, типа «Джаваокий ангел Дмитрий».
+1
Если честно реальность такова, что питон хорош по-большей части в проектах, где требуется какой-то расчет, математические модели и прочие штуки, связанные с работой с данными. Это объясняется наличием крутых математических и машин-лернинг библиотек.
Для всего остального — выбор питона это откровенная вкусовщина, которая ничем не объясняется, кроме как «Мы выбрали питон, так как нам нравился питон».
Django — убер удобный фреймворк для целого набора вещей. Тут вопросов нет.
Flask/Tornado/Twisted/aiohtp — уже неудобней и запутанней. И уже появляется вопрос, а нужно ли нам это все, и не взять ли что-то более «стандартное» для этого.
Для всего остального — выбор питона это откровенная вкусовщина, которая ничем не объясняется, кроме как «Мы выбрали питон, так как нам нравился питон».
Django — убер удобный фреймворк для целого набора вещей. Тут вопросов нет.
Flask/Tornado/Twisted/aiohtp — уже неудобней и запутанней. И уже появляется вопрос, а нужно ли нам это все, и не взять ли что-то более «стандартное» для этого.
0
Что входит в базис для веб-разработки на Python
- ...
- Протоколы и API: в первую очередь http, JSON-RPC, Protocol Buffers, gRPC.
- ...
Ебобо вообще?
0
Sign up to leave a comment.
Python для Веба: что нужно знать джуниору, чтобы работать и развиваться