Разработка python: Разработка на Python — Инфографика «Экосистема разработки в 2021 году»

Leave a Comment / Разное / By /

Содержание

Разработка на Python — Инфографика «Экосистема разработки в 2021 году»

Основные выводы

Образ жизни и интересные факты

Демография

Методология

Исходные данные

C

C#

C++

Go

Java

JavaScript

Kotlin

PHP

Python

R

Ruby

Rust

Scala

Swift и Objective-C

Big Data

Базы данных

DevOps

Образование

Встраиваемые системы

Микросервисы

Прочие технические вопросы

Инструменты для командной работы

Техническая документация

Тестирование

Вопросы о Python были заданы только тем, кто выбрал Python в качестве одного из трех основных языков программирования.

Какую версию Python вы используете чаще всего?

Только 3% разработчиков на Python продолжают использовать в 2021 году версию Python 2! Пять лет назад их доля составляла 47%.

С какой целью вы используете Python?

За последние 5 лет проведения опроса JetBrains «Экосистема разработки» основные сферы применения языка Python не изменились. Чаще всего он используется для веб-разработки и анализа данных — эти направления назвали примерно по 50% респондентов.

Лишь 4% пользователей Python разрабатывают игры, из них 77% занимаются этим в качестве хобби.

Язык программирования Python используют 75% респондентов, занятых научными исследованиями, — это самый популярный язык в данной сфере.

Какие веб-фреймворки/библиотеки вы используете в дополнение к Python?

Какие фреймворки для анализа данных вы используете в дополнение к Python?

Python и JavaScript — те языки, которые респонденты чаще всего изучают: почти 30% участников опроса изучали их в течение прошедших 12 месяцев.

Мы спросили, на каких платформах открытых онлайн-курсов люди чаще всего изучают Python, если они вообще пользуются такими платформами. Чаще всего респонденты называли Udemy, Coursera и edX. Если сравнивать с другими языками, интересно, что Udemy обычно мене популярна, в то время как Coursera и edX используются значительно чаще.

Компания JetBrains запустила собственную образовательную платформу — JetBrains Academy. Для изучения Python и обучения этому языку можно использовать специальную IDE PyCharm Edu.

Какие фреймворки/библиотеки вы используете в дополнение к Python?

Половина разработчиков, участвовавших в опросе, изучали Python, когда получали образование.

Какие еще технологии вы используете совместно с Python?

Доля разработчиков на Python, которые работают в очень крупных компаниях (свыше 5000 сотрудников), составляет 20% — это больше, чем среди других разработчиков (15%). Что касается компаний других размеров, соотношение примерно такое же, как и у остальных разработчиков.

Какую IDE или редактор вы чаще всего используете для разработки на Python?

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

Сегодня Python — основной язык для Data Science. Большинство разработчиков, занятых анализом данных (54%), инжинирингом данных (54%) и машинным обучением (71%), используют Python.

Компания JetBrains разработала несколько новых инструментов для Data Science, предлагающих широкие возможности.

Datalore — эффективная среда для Jupyter Notebooks. Она доступна для любых пользователей онлайн, а также ее можно установить локально в корпоративной среде.

DataSpell — новая IDE, разработанная JetBrains для Data Science. Это высокопроизводительная среда разработки для специалистов в области Data Science, которые активно занимаются разведочным анализом данных и прототипированием моделей машинного обучения.

Подробнее о состоянии экосистемы разработки на Python можно прочитать в официальном Отчете об опросе разработчиков на Python, подготовленном совместно с Python Software Foundation.

PyCharm

IDE для профессиональной разработки на Python

Datalore

Умное веб-приложение для анализа данных

PyCharm Edu

Профессиональный инструмент для обучения программированию на Python

DataSpell

Новая IDE от JetBrains для Data Science

Предыдущий раздел

PHP

Следующий раздел

R

Основные выводы

Образ жизни и интересные факты

Демография

Методология

Исходные данные

C

C#

C++

Go

Java

JavaScript

Kotlin

PHP

Python

R

Ruby

Rust

Scala

Swift и Objective-C

Big Data

Базы данных

DevOps

Образование

Встраиваемые системы

Микросервисы

Прочие технические вопросы

Инструменты для командной работы

Техническая документация

Тестирование

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

Примите участие в будущих опросах

Я хочу принимать участие в будущих опросах JetBrains

Я хочу получать результаты будущих исследований JetBrains

Я хочу получать электронные письма о новостях, продуктах и услугах компании JetBrains

By submitting this form I agree to the JetBrains Privacy Policy

Если у вас есть вопросы или пожелания, свяжитесь с нами по адресу [email protected].

Python — серьезный язык для разработки backend / Хабр

Всем привет! Меня зовут Денис Аникин, я тимлид в команде Chat в Райффайзенбанке. А также представитель внутреннего Python-сообщества, так называемый «community lead» (об этом как-нибудь в другой раз). В этой статье я хотел поговорить про отношение к Python среди разработчиков и обсудить все основные претензии, которые очень давно следуют за языком по пятам.

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

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

Также я вспоминаю нашу внутреннюю шутку, которая сформулирована моим коллегой, Даниилом: «Денис начинает свой понедельник с очередного доклада на тему, почему Python — серьезный язык». Я долго думал над этой шуткой (извините, я не гений), а потом решил: почему бы и не начать с этого статью? 🙂

Поэтому я хочу поговорить про проблемы Python и обсудить накопившиеся к нему основные претензии.

Динамическая типизация

За динамическую типизацию Python ругали практически все — это одна из крупнейших претензий к нему в среде разработчиков. Но на самом ли деле динамическая типизация — такое уж зло? Как минимум, разработка на языках динамической типизации проще, быстрее и зачастую приятнее — конечно, это субъективный тезис, но он имеет право на существование.

Какой-нибудь JSON-парсер на языке со статической типизацией будет гораздо более многословным и тяжелым в написании, чем на языке с динамической типизацией (ох уж эта элегантная связка orjson и pydantic). Где-то, где мы в Python отобьемся манипуляциями в рантайме, придется подтаскивать большие объёмы кодогенерации.

Аннотации — благо

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

При этом Uncle Bob говорил, что тесты на бизнес-логику не отменяются статической типизацией, да и в Python теперь типы можно проверять статически с помощью аннотаций и MyPy. Конечно, мы пишем больше тестов и тщательно проверяем бизнес-логику, но, на мой взгляд, это идет на пользу сервисам. Всё очень неоднозначно.

Да, у нас есть gradual типизация. MyPy, typing, аннотации типов — это позволяет нам значительно улучшить качество кода, уберечься от массы ошибок, получить экстрафункциональность языка. Например, в Python нет констант, но с помощью связки typing и MyPy можно получить их аналог. Аннотации в Python можно анализировать как статически, так и динамически: в typing есть интроспекция, появляются проекты вроде Beartype. 

На базе аннотаций типов построены современные фреймворки, такие как Pydantic (строгие схемы валидации в рантайме) или FastAPI. Я считаю вот так: Python в связке с аннотациями типов являет нам gradual типизацию и тем самым предоставляет здоровый компромисс между преимуществами динамической и статической типизаций. Он не порождает хтоническое чудовище, каким его часто объявляют в интернете. Напротив, нам дают способ писать и быстро и надежно, здесь и сейчас.

Где-то тут к нам подкрадывается вопрос о типобезопасности. Полагаю, что аннотации типов проверку на типобезопасность не пройдут, хотя вопрос это довольно сложный, не для моего уровня понимания. На текущий момент ошибок типов с MyPy и аннотациями типов я не встречал, но уверен, что где-то при определенном стечении обстоятельств это возможно. Единственное, что видно у нас — увеличение надежности нашего кода (пока мы пишем наши бэкенды, аннотации часто помогают отлавливать ошибки), умение гибридно использовать аннотации и почти никаких type error в коде.

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

Честно говоря, пункт уже раздулся, поэтому я просто набросаю свои мысли списком:

  • Статический анализ хорош везде;

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

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

Скорость

Этот аспект языка часто подвергается критике очень многими разработчиками. И если динамическая типизация — сложная и неоднозначная тема для обсуждения, то скорость — то, о чем говорят вообще все. 

Если посмотреть на синтетические бенчмарки, то Python часто можно обнаружить в самому низу турнирных таблиц. Многие разработчики считают это Ахиллесовой пятой Python, что не может не сказываться на восприятии языка

Когда обсуждают скорость Python, обычно вспоминают про C++, ведь на нем все бенчмарки выглядят в сто раз лучше, чем на Python. Но если мы начнём разбираться в вопросе, то станет ясно, что скорость Python на данном этапе — не такая уж проблема. Конечно, Python действительно медленный в CPU-bound задачах. И тут у вас в голове возникает мысль — если он такой медленный, то это точно проблема!

На мой взгляд, дело обстоит так. В современной web-разработке полно i/o-bound нагрузки: часто мы принимаем запросы по сети, отправляем их в сеть, читаем из БД, пишем в БД, оперируем с файлами и так далее.

Одни из действующих «лиц» CPU-bound и IO-bound задач

Для этого типа задач у Python есть прекрасный ответ — асинхронный подсет языка, нативный async/await, event loop из коробки и uvloop, для тех, кто хочет ещё быстрее. С помощью этой части Python мы можем эффективно утилизировать ресурсы CPU. А для исключительно CPU-bound в мире Python тоже много «припарок»: multiprocessing, subprocess, Pypy, Cython, Numba и так далее. Поэтому асинхронный Python работает очень даже быстро.

Подведу субъективный итог: многое, если не всё, можно смело писать на Python, а CPU-bound, при необходимости (если стандартная библиотека не тянет), переписывать на более быстрых языках и ставить эти микросервисы-воркеры за очередями сообщений. Разве это не идеальное сочетание?

Язык для новичков

Довольно часто Python считают языком для новичков. Ему учат на каждом шагу, в мире миллион курсов по Python. Топовые блоггеры обещают обучить ему чуть ли не за один вечер, говорят, что все сразу же получают серьезную зарплату, уютный офис и счастливое будущее. На этом слишком радужном фоне за Python прочно закрепился имидж языка для новичков, где достаточно написать пару for и def, объявить несколько переменных — и вот ты уже профессиональный Python-разработчик уровня middle. А потом «перерастаешь» и идешь писать на «серьезном языке».

Это все какой-то интернет-морок, потому что Python, как и любой другой язык, требует освоения, изучения, времени.

В самом языке у нас целая куча всяких знаний, нюансов, сложностей и декларативных частей. Судите сами:

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

  • Декораторы. Здесь тебе и функции высшего порядка, замыкания, три уровня вложенности для параметризированных декораторов — слишком много всего для такого «простого» языка. Я сам по началу долгое время не понимал паттерн «декоратор», с трудом писал их. И я знаю, что у многих с этим есть проблемы, это видно как минимум на собеседованиях.

  • Метаклассы. Классы, создающие классы? Функция type, она же класс? А тип type — тоже type? Все классы создаются type? Популярный сценарий применения — ORM? Можно, пожалуйста, мне другой «простой» язык?

  • Библиотека functools в полном составе 🙂

  • Генераторы. Можно спрашивать на собеседованиях: «А для чего вы используете генераторы?» — и услышать очень много разных ответов. Некоторые вообще не понимают, зачем они нужны. А ведь генератор поддерживает протокол итерации, в него можно слать значения, yield from — ну, сами все понимаете.

  • Контроль зависимостей. Venv, virtualenv, pipenv, poetry, pip tools, pdm, pipx, pyproject и так далее.

  • Инфраструктура вокруг Python. Крайне полезно для работы было бы знать, что такое pypa, pypi, psf — а это ещё отдельный пласт знаний.

  • PEP. Иногда спрашиваю людей: «А что такое PEP?», — и самый частый ответ: «Стандарт кода». Даже опытные разработчики помнят PEP8 в лучшем случае.

  • Около сотни магических методов. Хорошо было бы в них просто ориентироваться.

  • Могущественная интроспекция и «мета-язычные» вещи. Runpy, importlib, trace, traceback, gc, inspect, sys, typing.get_type_hints, typing.get_origin, typing.get_args.

  • Встроенные классы ошибок, методов и типов. Можете выполнить и получите 156: import builtins; len(dir(builtins)). Это количество встроенных классов ошибок, методов, типов. Желательно помнить многое из этого.

  • Новые вещи. Оператор «морж», pattern matching.

  • Конкурентное выполнение. Threading с кучей нюансов, multiprocessing, subprocess, свежий communicating sequential processes «паттерн» (PEP 554).

  • GIL. Комментарии не нужны, но они будут (я не умею лаконично, помогите).

  • Особые языковые возможности. Dict, list, set comprehensions, generator expressions, например.

  • Асинхронность. Это отдельный «подсет» языка, где уже целая своя вселенная с кучей пакетов и даже отдельными (не встроенными в язык) концепциями, вроде structured concurrency.

  • Аннотации типов. Или аннотированный Python — тоже, считай, свой мини-«подсет» языка, вводящий новый понятийный аппарат, и новый вид типизации — структурную саб-типизацию, ближайшим аналогом которой из мира динамической типизации можно было бы назвать утиную.  

  • Динамическая типизация. Строгая (местами «обходимая» полимформизмом, или неявным приведением int к float), утиная типизация, typing.Protocol (про него выше), gradual типизация. Скажите мне — это правда так просто?

Типичный диалог (а иногда и монолог) в интернете

И я бы мог ещё продолжать какое-то время. Этот список я составил не для того, чтобы отпугнуть от языка, но мне хочется продемонстрировать, что Python — не такой простой язык программирования. Действительно, на нём легко начать, у него низкий порог первоначального входа. Но это вовсе не язык только лишь для новичков, такое отношение к нему порождает безответственный подход к разработке. Язык взял много хорошего от других, он не простой, со своими плюсами и минусами, очень красивыми местами и не самыми лучшими. И всё это требует освоения.

GIL 

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

Ограничения GIL известны всем — в Python при попытке распаралеллить любую CPU-bound нагрузку с помощью тредов, разработчики неизбежно сталкиваются с тем, что в один момент у всегда будет работать только один поток. Тема абсолютно выдающаяся и имеющая за собой такой поток реминисценций, что про это даже немного неловко говорить, — но поговорить нам, всё-таки, в рамках статьи нужно.

Издалека проблема GIL — и сложная, и, как кажется, практически нерешаемая (мы все помним, что на этот счет сказали Гвидо, Дэвид Бизли; UPD: тут недавно вышла статья, говорят о nogil… но давайте не будем об этом). 

В современных бэкендах и Python накал страстей вокруг GIL сильно стих — веб-сервисы очень часто по своей природе могут быть асинхронными, а для этого у нас есть множество чудесных фреймворков, вроде FastAPI, поэтому ограничения GIL нас не так сильно касаются. При этом горизонтально мы масштабируемся процессами, как в синхронных бэкендах, так и в асинхронных. У многих есть кубер — и там мы масштабируемся тоже процессами, только над ними стоит абстракция уровнем выше — pod.

Изрядно поношенный GIL

Некоторые разработчики спрашивают, зачем нам тогда треды? 

В современном Python их используют для одной интересной штуки — на них можно делать wannabe-асинхронный код, при этом не делая асинхронный код, как ни странно. То есть можно написать на тредах что-то, что занимается интенсивной i/o-нагрузкой. И тогда внезапно все станет асинхронным за счет того, что GIL отпускается на i/o-операциях. 

Это важное примечание, так как это сложный и неочевидный нюанс работы GIL — он описан в документации, но кто же её читает — шутка :). Но благодаря ему мы можем получить преимущество даже в синхронном коде, а также не блокировать петлю событий, когда у нас возникает потребность вызвать синхронное i/o в петле событий (вспомним про запись файлов, привет экзекьюторам).

Python — «неказистый язык для набрасывания прототипов на Django»

Частое мнение в интернете — Python годен только для быстрого, реактивного набрасывания прототипов на Django, а все остальное удел «серьезных языков» (тм). И это ещe одно, с моей точки зрения, не очень корректное суждение. 

Конечно, на Django, на Python быстро набрасывают прототипы — я не буду отрицать очевидного. Но на языке делают не только это, описанное — лишь малая часть возможностей экосистемы Python. Однако быстро прототипирующие люди, использующие язык одним способом, почему-то взяли на себя прерогативу оценивать позиционирование языка по своей сфере. И с этим я не согласен. 

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

Pytest — это прекрасный фреймворк для написания тестов и яркий представитель этого тулсета. Он позволяет выстраивать очень сложные тестовые сценарии с инверсией зависимостей всего с помощью двух инструментов — fixtures и parametrize. С их помощью можно делать очень сложные тесты — подробно изучать производительность и бизнес-логику системы.

В тестировании, помимо Pytest, у нас есть Hypothesis — отличный фреймворк для fuzzy, property тестирования. Фреймворк настолько впечатляет, что недавно, на Python Language Summit 2021, стало известно, что его используют core developer’ы и с помощью него нашли ошибки в PEG парсере самого Python.

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

from hypothesis import given
from hypothesis.strategies import text
def encode(input_string: str) -> list:
    """Это просто синтетический пример."""
    count: int = 1
    prev: str = ""
    lst: list = []
    character: str
    for character in input_string:
        if character != prev:
            if prev:
                lst.append((prev, count))
            count = 1
            prev = character
        else:
            count += 1
    lst.append((character, count))
    return lst
def decode(lst: list) -> str:
    """Это просто синтетический пример (2).
  """
    q: str = ""
    character: str
    count: int
    for character, count in lst:
        q += character * count
    return q
@given(text())
def test_decode_inverts_encode(s):
    """И здесь мы получаем совершенно невероятный объем тестов. При том, 
    что повесили 1 декоратор."""
    assert decode(encode(s)) == s

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

Вообще, в Python есть огромное количество вспомогательных библиотек для тестирования — Faker, Factory boy, Mixer, Seed, куча расширений для Pytest — например, для параллелизации. Поэтому говорить, что Python можно использовать только для быстрого прототипирования на Django — немного некорректно.

Безопасность

Как-то раз нам написали комментарий, что за Java и C# стоят крупные компании, бизнес, а за Python только Гвидо и никакой ответственности нет. Видимо, это означало, что языком пользоваться страшно и от этого он абсолютно несерьезен.

Мне кажется, этот вопрос довольно сложный. Крупные проблемы языковой среды — не такой уж и частый сценарий. Но вряд ли при серьезных проблемах разработчики на Java или C# моментально получат их решение.

А ещё можно вспомнить, что современный софт пишется с использованием огромного количества Open Source библиотек, которые пишутся сторонними разработчиками, лежат в открытом доступе — и баги там случаются часто, а гарантий их исправления нет и быть не может. Тогда как серьезные проблемы Python, в случае их возникновения, точно будут исправлены. К тому же у Python «сжался» релизный график.

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

Популярность

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

У нас есть аналитика GitHub, здесь Python сразу за JavaScriptGoogle-тренды довольно наглядно показывают, что Python очень долго рос все эти годы и умудрился своей неспешной змеиной «походкой» обогнать мощных конкурентовРейтинг PYPL (некоторые говорят, что он не очень объективен)Любимый многими RedMonk. Кто-то считает его довольно объективнымМенее известный рейтинг IEEE Spectrum, который агрегирует данные из 11 источников, включая (но не только) некоторые из описанных выше и нижеStackoverflow говорит, что по популярности Python сейчас третийВот и всем известный и бесконечно критикуемый TIOBE

Причин роста много, но кроме известных, для себя я предпочитаю выделять такую: одна из сильнейших черт Python в том, что он по пути вбирал в себя огромное количество разных парадигм и подходов, зачастую беря из них если не лучшие, то как минимум хорошие куски. Именно поэтому он умудряется быть таким универсальным и при этом довольно дружелюбным. Хм, дружелюбный сосед-питон? (шутка, предоставлена ЗАО «бумер-кринж»).

И о минусах

Что? Секундочку, ведь я только что активно поддерживал Python, а теперь начинаю перечислять минусы? Дело в том, что мне не хочется выглядеть как фанатик в розовых очках. Поэтому я просто назову уже не совсем типовые вещи, но тоже часто встречающиеся:

  • Некоторые не любят пробелы… вспомним Whython. Я до сих пор не понимаю, в чем проблема — я везде код форматирую пробелами, а в Python они дают возможность избежать написания «лишних» скобок. Но не признать того, что есть недовольные, нельзя.

  • Python 2 и 3. Это неактуальный топик на текущий день, и Python 3 принес столько невероятных вещей, что о второй версии говорить нет желания. Но стоит признать — это было больно, и многие ещё помнят, насколько болезненно дался переход. Некоторых это отвращает от языка: подсознательно ты ждешь Python 3 vs 4.

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

Небольшие итоги

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

Python используется большинством авторитетных компаний, таких как Google и Яндекс. При этом популярность языка продолжает расти, а так же Гвидо недавно на Python Language Summit 2021 обещал, что с поддержкой Microsoft он сделает Python быстрее раз в пять, во многом с помощью jit. Может быть из конца списка языков в бенчмарках мы переместимся в середину, и уж там то точно заживем.

В Python фантастические веб-фреймворки. Можем вспомнить Django или FastAPI — это выдающиеся фреймворки, со своими плюсами и минусами. Современный Python можно брать для написания быстрых, хороших и серьезных бэкендов. В Python-среде много крутых разработчиков и приятных людей!

Python жутко популярен и продолжает расти. Потенциал его роста не исчерпан.

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

А ещё на Python очень приятно писать код — и этого совершенно не стоит стесняться.

Эта статья — расширенная версия доклада с IT-конференции Райффайзенбанка <code/R>. Здесь много новых подробностей, но если хотите услышать часть голосом — смотрите видео.

Руководство разработчика Python

Изменить эту страницу

Переключить боковую панель оглавления

Это руководство представляет собой исчерпывающий ресурс для внесения на Python — как для новых, так и для опытных участников. это поддерживается тем же сообщество, поддерживающее Python. Мы приветствуем ваш вклад в Python!

Краткий справочник

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

  1. Установка и настройка Git и других зависимостей (подробную информацию см. на странице настройки Git).

  2. Разветвить репозиторий CPython в свою учетную запись GitHub и получите исходный код, используя:

     клон git https://github.com/
     /cpython
компакт-диск cpython

  3. Сборка Python, в UNIX и macOS используйте:

     ./configure --with-pydebug && make -j

    и в Windows используйте:

     PCbuild\build.bat -e -d

    См. также более подробные инструкции, как установить и построить зависимости, и страницы для конкретных платформ для UNIX, macOS и Windows.

  4. Запустить тесты:

     ./python -m тест -j3

    В большинстве систем macOS замените ./python . с ./python.exe . В Windows используйте python.bat .

  5. Создайте новую ветку, в которой будет проходить ваша работа над проблемой, например:

     git checkout -b fix-issue-12345 основной

    Если проблема еще не существует, создайте ее.

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

  6. После устранения проблемы запустите тесты, запустите , выполните проверку исправлений и, если все в порядке, коммит.

  7. Разместите ветку на своем форке на GitHub и создайте запрос на вытягивание. Включите номер выпуска, используя gh-NNNN в Описание пулреквеста. Например:

     gh-12345: исправлена ​​ошибка в спам-модуле.

  8. Добавить запись новостей в каталог Misc/NEWS.d в виде отдельного файла. запись новостей может быть создана с помощью аннотации, или инструмент аннотации и его аннотация добавить команда. Пожалуйста, прочитайте больше о рекламе в документации.

Примечание

Вступающие впервые должны будут подписать Лицензию участника Соглашение (CLA), как описано в разделе «Лицензирование» это руководство.

Быстрые ссылки

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

  • Система отслеживания проблем

  • Статус билдбота

  • Где получить помощь

  • PEP (предложения по улучшению Python)

  • Git Bootcamp и шпаргалка

Содействие

Мы призываем всех внести свой вклад в Python, поэтому мы разместили это руководство разработчика. Если у вас остались вопросы после ознакомления с материалом в этого руководства, то группа Core Python Mentorship доступна, чтобы помочь новым участников в процессе.

Несколько человек из сообщества Python внесли свой вклад в серию отличных руководств на Open Source Guides.

Основные разработчики и участники найдут полезными следующие руководства:

  • Как внести свой вклад в Open Source

  • Создание доброжелательных сообществ

Руководство по разработке Python:

Авторы

Документалисты

Триагеры

Основные разработчики

Установка и строительство

Помощь с документацией

Система отслеживания проблем

Обязанности

Где получить помощь

Начало работы

Рассмотрение проблемы

Журнал разработчика

Жизненный цикл запроса на слияние

Руководство по стилю

Помощь в вопросах сортировки

Принятие запросов на вытягивание

Запуск и запись тестов

reStructuredText Primer

Указатель экспертов

Цикл разработки

Решение «простых» проблем (и не только)

Перевод

Ярлыки GitHub

Мотивы и связи

После разработки Python

Проблемы GitHub для пользователей BPO

Часы работы основных разработчиков

Git Bootcamp и шпаргалка

Группа сортировки

Указатель экспертов

Цикл разработки

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

Предложение изменений в самом Python

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

Хотя такие изменения происходят гораздо реже, чем описанные выше, они случиться, и этот процесс также описан в этом руководстве:

  • Добавление в стандартную библиотеку

  • Изменение языка Python

Другие реализации интерпретатора

Это руководство предназначено специально для поддержки эталонного интерпретатора Python, также известный как CPython (хотя большая часть стандартной библиотеки написана на Python, ядро интерпретатора написано на C и легче всего интегрируется с C и экосистемы С++).

Существуют и другие реализации Python, каждая со своей направленностью. Нравиться CPython, у них всегда есть больше вещей, которые они хотели бы сделать, чем они имеют разработчиков для работы над ними. Некоторые основные примеры, которые могут представлять интерес:

  • PyPy: интерпретатор Python, ориентированный на высокоскоростную (JIT-компиляцию) работу. на основных платформах

  • Jython: интерпретатор Python, ориентированный на хорошую интеграцию с Java. Среда виртуальной машины (JVM)

  • IronPython: интерпретатор Python, ориентированный на хорошую интеграцию с Общеязыковая среда выполнения (CLR), предоставляемая .NET и Mono

  • Stackless: интерпретатор Python, ориентированный на предоставление легкого микропотоки, оставаясь в значительной степени совместимыми со специфическими для CPython модули расширения

  • MicroPython: крошечный интерпретатор Python с небольшим подмножеством Python стандартная библиотека, оптимизированная для работы на микроконтроллерах и в стесненные среды.

  • CircuitPython: ответвление MicroPython, предназначенное для упрощения экспериментов. и обучение программированию на недорогих платах микроконтроллеров.

Ключевые ресурсы

Дополнительные ресурсы

  • Любой может клонировать исходники этого руководства. Видеть Помощь с Руководством разработчика.

  • Помощь с …

    • Изучение внутренних органов

    • Изменение грамматики CPython

    • Руководство по синтаксическому анализатору

    • Дизайн компилятора

    • Конструкция мусоросборника

  • Опора для инструмента

    • Опора GDB

    • Динамический анализ с Clang

    • Различные инструменты с файлами конфигурации, найденными в каталоге Misc

    • Информацию о редакторах и их конфигурациях можно найти в вики

  • обслуживание python. org

  • Искать в этом руководстве

Кодекс поведения

Обратите внимание, что все взаимодействия на Поддержка Python Software Foundation инфраструктура покрыта Кодексом поведения PSF, который включает в себя всю инфраструктуру, используемую при разработке самого Python (например, списки рассылки, средства отслеживания проблем, GitHub и т. д.). В целом это означает, что все должны быть открытыми, внимательными и уважать других, независимо от их положения в проекте.

Статус веток Python

Перемещено в Статус версий Python

Полное содержание

Статус версий Python

Наверх Изменить эту страницу

Переключить боковую панель оглавления

Основной веткой в ​​настоящее время является будущий Python 3.12, и это единственная ветвь, которая принимает новые функции. Последний выпуск для каждого Python версию можно найти на странице загрузки.

Цикл выпуска Python

’08 ’09 ’10 ’11 ’12 ’13 ’14 15 лет ’16 ’17 18 лет ’19 20 лет 21 год 22 года 23 года 24 года 25 лет 26 лет 27 лет 28 лет Питон 2.6 конец жизни Питон 2.7 конец жизни Питон 3.0 конец жизни Питон 3.1 конец жизни Питон 3.2 конец жизни Питон 3.3 конец жизни Питон 3. 4 конец жизни Питон 3.5 конец жизни Питон 3.6 конец жизни Питон 3.7 безопасность Питон 3.8 безопасность Питон 3.9безопасность Питон 3.10 Исправлена ​​ошибка Питон 3.11 Исправлена ​​ошибка Питон 3.12 характерная черта

Поддерживаемые версии

Даты, выделенные курсивом , запланированы и могут быть скорректированы.

Филиал

Расписание

Статус

Первый выпуск

Конец срока службы

Менеджер выпуска

основной

ПКП 693

функция

2023-10-02

2028-10

Томас Воутерс

3. 11

ПКП 664

Исправление

24.10.2022

2027-10

Пабло Галиндо Сальгадо

3.10

ПКП 619

Исправление

04.10.2021

2026-10

Пабло Галиндо Сальгадо

3,9

ПКП 596

безопасность

05.10.2020

2025-10

Лукаш Ланга

3,8

ПКП 569

безопасность

14.10.2019

2024-10

Лукаш Ланга

3,7

ПКП 537

безопасность

27. 06.2018

27.06.2023

Нед Дейли

Неподдерживаемые версии

Филиал

Расписание

Статус

Первый выпуск

Конец срока службы

Менеджер выпуска

3,6

ПКП 494

окончание срока службы

23.12.2016

23.12.2021

Нед Дейли

3,5

ПКП 478

окончание срока службы

13.09.2015

30.09.2020

Ларри Хастингс

3,4

ПКП 429

окончание срока службы

16. 03.2014

18.03.2019

Ларри Гастингс

3,3

ПКП 398

окончание срока службы

29.09.2012

29.09.2017

Георг Брандл, Нед Дейли (3.3.7+)

3.2

ПКП 392

окончание срока службы

20.02.2011

20.02.2016

Георг Брандл

3.1

ПКП 375

окончание срока службы

27.06.2009

09.04.2012

Бенджамин Петерсон

3,0

ПКП 361

окончание срока службы

03.12.2008

27.06.2009

Барри Варшава

2,7

ПКП 373

окончание срока службы

03.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *