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

    Мы сделали сокращенную расшифровку с главными мыслями из Python Junior Podcast: в нем мы обсудили, с чего начинать и куда податься начинающему разработчику на Python. В последнее время у нас много контента для миддлов и сеньоров, но этот выпуск — точно для джунов.




    Главные темы:

    • Какие знания нужны начинающему программисту, чтобы заниматься
      веб-разработкой?
    • Чего ждут работодатели от разработчиков?
    • Что делать, чтобы найти работу без опыта?
    • Как может развиваться Python-разработчик?

    Python Junior Podcast — подкаст о программировании для тех, кто хочет лучше разбираться в Python. Эфиры ведут евангелисты сообщества MoscowPython и преподаватели курсов Learn Python.

    В разговоре участвовали:

    • Валентин Домбровский,сооснователь MoscowPython
    • Злата Обуховская, тимлид NVIDIA
    • Григорий Петров, евангелист MoscowPython
    • Алексей Штырняев, разработчик в FinEx, преподаватель курсов Learn
      Python

    Почему Python хорош для веб-разработки


    Валентин Домбровский: Почему именно Python подходит для веб-разработки? Почему не PHP или JavaScript, например?

    Григорий Петров: Так ведь выбора особо нет. Несмотря на то что в современном Вебе можно фактически без бэкенда — чисто на фронтенд-технологиях, на JavaScript — собрать себе single page application или progressive web application, все равно это слишком сложно, плохо индексируется и требует крутых разработчиков.

    Если мы хотим сделать сайт или сервис, мы используем комбинированный подход: у нас какой-то бэкенд осуществляет логику и создает веб-страницы и какой-то фронтенд рисует эти веб-страницы в браузере. И когда нам надо быстро это все на чем-то собрать, то выбора особо нет.

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

    • C#. Microsoft действительно молодцы, они сделали .NET Core и всячески ее продвигают. Но, во-первых, это новая кроссплатформенная технология, и там еще не все гладко. Во-вторых, это действительно дорого, разработчиков C# мало — просто потому, что она непопулярна.
    • Java. Это сложно. Сделать нормальный сайт на Java — это не 10 строчек кода, как на Python. Это много кода, это фреймворки, и нужно знать специфику настройки Java-серверов. В общем, сплошные боль и страдания.
    • PHP. В последних версиях он замечательный. Я даже так скажу: PHP 7.2 не хуже Python. Но нельзя просто так взять и использовать PHP 7.2. Если обычный, не топовый разработчик делает сайт на PHP, он не будет писать только на 7.2: все равно придется читать какие-то учебники, туториалы, везде куча legacy-кода, и это не очень хорошо.
    • JavaScript и Node.js. Это замечательно и очень современно, когда один язык и на фронтенде, и на бэкенде. Только не очень стабильно. Node.js — хорошая штука, но проблематично развернуть ее в продакшене так, чтобы она не падала и работала устойчиво. Плюс, если мы хотим писать качественный код на JavaScript, нам нужен не JavaScript, а TypeScript. А вот TypeScript неожиданно сложный, при виде него у рядового разработчика вскипают мозги.

    Давайте опустим Ruby, Haskell, Erlang и другие нишевые штуки, и у нас остается… Python. Язык с консистентным синтаксисом, единообразной стандартной библиотекой, лучшей документацией, популярными легкими фреймворками, мегапопулярным комбайном Django.
    Получается, что, несмотря на широчайший выбор, если у нас обычные, не топовые разработчики, мы обычный бизнес, который хочет делать обычные сайты, у нас нет отдела разработки на 50 человек, то мы берем Python.

    Какие знания нужны для входа в профессию


    Злата Обуховская: Я считаю, что один фреймворк нужно знать хорошо — и знать, какие еще бывают и когда они используются. Где Tornado, где Django, где Flask, где aiohttp и так далее.
    Пригодится знать, что есть такая штука, как протоколы. В частности, знание протокола http — центральное для построения веб-приложений.

    Еще нужно хотя бы приблизительно представлять себе, как в веб-проектах устроен фронтенд: что есть HTML, CSS, JS.

    Алексей Штырняев: И знать, где лежит документация. Это самое главное.

    Григорий Петров: Тут мы ступаем на очень зыбкую почву. Если нам не повезло и мы начали как-то серьезно изучать современный фронтенд, то он будет примерно раз в 10 сложнее, чем бэкенд на Python. Начинающему разработчику нужно ограничить свой фокус так, чтобы начать изучать HTML, но чтобы не провалиться во все эти div, span, float, как там все выравнивается и выстраивается.

    Алексей Штырняев: Нужен базовый курс по Bootstrap. И основы HTML.
    В первый год не стоит углубляться в JS-фреймворки (если вы фокусируетесь на бэкенде). В базовом курсе по Bootstrap уже есть готовые модули: хочешь слайдер — делай слайдер, хочешь плавающее меню — сделай плавающее меню.
    Злата Обуховская: Думаю, что за изучением фронтенда можно погрузиться, в частности, в то, как вообще статика отдается веб-приложениям. Так разработчик плавно переходит к тому, чтобы начать узнавать, как в принципе устроена архитектура веб-приложений и как они живут на продакшене.

    Григорий Петров: Да, порекомендую сразу на тот случай, если вы выбрали Python в качестве языка бэкенд разработки и, например, Django в качестве фреймворка: у Django есть документация в Django Book, она реально клевая, в ней все то, о чем сказала Злата, она и правда хороша для начинающего.

    Алексей Штырняев: Еще для быстрого старта подойдет какой-нибудь Django Girls, если цель — изучить именно Django. Это такой туториал, где за один день можно пройти по верхам, понять основы и то, на что способен фреймворк.

    Валентин Домбровский: Готовясь к записи подкаста, мы составили список того, что нужно программисту на Python для веб-разработки, чем и резюмируем ранее сказанное.

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


    • Веб-фреймворки Django, Flask, aiohttp, Tornado и т. д. (и знать о существовании остальных).
    • Протоколы и API: в первую очередь http, JSON-RPC, Protocol Buffers, gRPC.
    • ORM и миграции, реляционные базы данных, SQLAlchemy, SQL, PostgreSQL, MySQL.
    • Основы HTML, CSS, Bootstrap, а также JS-фреймворки и JQuery.
    • Принципы работы приложений на продакшене, тестирование, юнит-тесты, автотесты, системы контроля версий, git.

    Нужны ли джуниору алгоритмы


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

    Григорий Петров: Я хочу подлить масла в огонь. Вот откуда вообще берется наша тяга к алгоритмам?

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

    Это пытаются делать, но тут у нас история Хогвартса: мы не можем сделать школу волшебников, пока у нас нет ни одного волшебника. Поэтому что делать университету, в который приходят и просят: «Начните обучать программистов», а программистов у них нет, потому что все работают в Mail.ru, Rambler и «Яндексе», им там хорошо?

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

    В итоге получается, что это настолько же целесообразно, как обучать строителя физике элементарных частиц лишь потому, что кирпич и цемент состоят из элементарных частиц.

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

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

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


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

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

    Валентин Домбровский: Мне такое сравнение пришло на ум: это перевод с языка бизнеса на язык, на котором можно общаться с компьютером. То есть программист — эдакий специфический лингвист.

    Григорий Петров: Бизнесу нужен писатель, а не лингвист. Писателю не нужно знать, почему тысячу лет назад это слово трансформировалось вот в то. Ему надо уметь применять эти слова.

    Что нужно, чтобы найти первую работу разработчиком


    Алексей Штырняев: Наверное, нет универсального рецепта, по которому нужно готовить джуниора.
    Если вы приходите в какую-то компанию, вас возьмут не за то, что вы знаете Django, JSON и немного алгоритмов. Вас, скорее всего, возьмут за те скиллы, которые здесь и сейчас нужны этой компании.
    Компаний много, и у всех разные требования. Нет такого универсального объема знаний, которые нужно получить, чтобы дальше подготовить резюме и идти трудоустраиваться.

    Григорий Петров: Когда мы в VoxImplant искали нескольких джунов, наш технический директор сформулировал базовое требование так: человек должен уметь решать задачи. Понятно, что джун это будет делать не всегда эффективно, не лучшим способом и не всегда правильно, но в идеале ты ставишь человеку задачу, он напрягается и решает ее. Это тот скилл, который в первую очередь ищут работодатели.

    Злата Обуховская: Люди, которые ищут работу, переходя из других областей, имеют с точки зрения бизнеса некоторое преимущество, потому что уже прошли какой-то путь и умеют решать задачи быстро. Это soft skills, я бы это назвала даже трудовой культурой. Зачастую у выпускников вузов эта трудовая культура еще не наработана.

    Но мне бы хотелось все-таки попытаться дать какой-то рецепт начинающим.

    Первые шаги для начинающего разработчика


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

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

    Валентин Домбровский: Кстати, мы на курсах готовим учеников к тому, чтобы у них появился свой проект за 10 недель обучения. Плюс тренируем навык командной разработки. Это как раз те soft skills, о которых говорила Злата.

    Алексей Штырняев: По опыту скажу, что первую работу можно искать очень долго. Когда вы ищете месяц-два — это нормально. Если вы подаете резюме во все компании, ходите на собеседования, на третий месяц вы обязательно что-то найдете.

    Валентин Домбровский: Можно пилить свои проекты или брать простые проекты на фрилансе и параллельно заниматься рассылкой резюме.

    Какие перспективы есть у Python-разработчика


    Злата Обуховская: Python-разработчик может пойти куда угодно. Можно пойти в тестирование, продолжить развиваться до senior-архитектора. Или даже в менеджмент. Технические менеджеры бывают разные, и можно дорасти до топ-менеджмента. Можно развиваться в data science, DevOps, пойти в автотесты или machine learning.

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

    ***

    Это лишь часть выпуска Python Junior. Полную версию эпизода можно послушать.

    Или даже посмотреть:


    RSS подкаста

    Спасибо, что прочитали, послушали или посмотрели.
    Поделиться публикацией

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

                  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__ пакета чтобы конструкции импорта которые уже юзали сохранили обратную совместимость при различных конструкциях импорта.

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

                        • 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
                          –2
                          Go забыли. А он имеет в вебе довольно сильные позиции. Да и разрабатывался с учетом веб-применения.

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


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

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

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

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

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

                                И все это, замечу, без каких-либо ухищрений как с CPython, а штатным компилятором.
                                  0
                                  А что вы называете ухищрениями?
                          +1
                          и нужно знать специфику настройки Java-серверов.

                          В смысле уметь -Xmx указывать?
                            +1
                            Сооснователь, евангелист и преподаватель))
                            А программистов-питонщиков про питон нельзя было спросить, обязательно людей с какими то странными регалиями?
                            Надо себе тоже чонить придумать, типа «Джаваокий ангел Дмитрий».
                              0
                              Если честно реальность такова, что питон хорош по-большей части в проектах, где требуется какой-то расчет, математические модели и прочие штуки, связанные с работой с данными. Это объясняется наличием крутых математических и машин-лернинг библиотек.

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

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

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

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

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

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

                                Самое читаемое