Python считается одним из самых популярных языков для создания веб-сервисов. За его плечами как скорые, небрежные RESTful API, так и полноценные веб-приложения, обслуживающие миллионы пользователей. Работающие в данной сфере наверняка уже использовали некоторые популярные фреймворки для создания сайта — Django, Flask, Falcon, Tornado или CherryPy.
За последние пару лет появилось довольно много неплохих фреймворков, и создается впечатление, что ветеранам скоро придется подвинуться. Новые веб-фреймворки используют свежий подход к решению проблем, делая акцент на производительности и выразительности API. Рассмотрим 11 новых веб-фреймворков Python, на которые вам стоит обратить внимание.
Sanic позиционирует себя как веб-сервер и веб-фреймворк, созданный для быстрого запуска. Он позволяет использовать синтаксис async/await, добавленный в Python 3.5. По этой причине код не блокируется и отличается скоростью выполнения. Sanic использует uvloop и ujson, когда нужно помочь с производительностью, однако данные пакеты являются опциональными.
Starlette является легким фреймворком ASGI, что идеален для создания высокопроизводительных сервисов asyncio. Он может использоваться как самостоятельный фреймворк, так и как инструментарий ASGI. Поставляется вкупе с обширным ассортиментом инструментов, поддерживает WebSockets, GraphQL, внутрипроцессовые фоновые задачи, а также текстовый клиент, построенный на Requests Python.
Masonite является веб-фреймворком Python, сконцетрированном на разработке. Он стремится соответствовать подходу «все включено». Это отличный инструментарий программиста с огромным количеством функционала и чрезвычайно растяжимой архитектурой.
FastAPI является современным, высокопроизводительным веб-фреймворком для создания API на Python 3.6+ основанный на подсказки типов Python. Создан поверх Starlette и является одним из самых быстрых и доступных фреймворков Python.
FastAPI базируется, а также является совместимым, с открытыми стандартами для API — OpenAPI (ранее известный как Swagger) и JSON Schema.
Responder также основан на Starlette. При создании Responder главной идеей было совместить лучшие аспекты Flask и Falcon внутри одного-единcтвенного фреймворка.
У него есть встроенный статический сервер для продакшена, автоматические gzip-ответы, нативная поддержка GraphQL и встроенный клиент для тестов, использующий модуль Requests.
Molten является минималистичным, расширяемым, быстрым и производительным фреймворком для создания HTTP API на Python. Molten автоматически проверяет запросы на соответствие с предопределенными схемами, гарантируя, что обработчики будут запускаться только при наличии правильного ввода.
Japronto является быстрым, масштабируемым, асинхронным HTTP инструментарием для Python 3.5+, интегрированным с конвейерным HTTP-сервером, базирующимся на uvloop и picohttpparser.
Он предназначен тех, кому важна скорость, внимательность к деталям и новые разработки. На данный момент нет особых новостей касательно разработки Japronto, однако о том, что проект заброшен, создатели также не сообщали.
Klein — это микро-фреймворк для разработки веб-сервисов на Python. Klein отличается минималистичным API, что похож на Bottle и Flask. Стоит отметить, что он зависим от дополнительных инструментов вне стандартной библиотеки.
Причина в том, что Klein создан на широко используемых и хорошо протестированных компонентах, таких как Werkzeug и Twisted.
Quart является Python ASGI веб-микрофреймворком. Он предназначен для того чтобы предоставить самый простой способ использования асинхронных функций в веб-контексте, особенно с уже существующими приложениями Flask.
Это становится возможным, благодаря тому, что Quart API является супер-набором для API Flask. Quart позиционирует себя в качестве полноценного веб-микрофреймворком. Он поддерживает HTTP/1.1, HTTP/2 и вебсокеты.
BlackShepp является асинхронным веб-фреймворком для создания веб-приложений Python, которые не блокируются и в основе которых лежат события. Вдохновлен Flask и ASP.NET Core.
За последние пару лет появилось довольно много неплохих фреймворков, и создается впечатление, что ветеранам скоро придется подвинуться. Новые веб-фреймворки используют свежий подход к решению проблем, делая акцент на производительности и выразительности API. Рассмотрим 11 новых веб-фреймворков Python, на которые вам стоит обратить внимание.
Sanic позиционирует себя как веб-сервер и веб-фреймворк, созданный для быстрого запуска. Он позволяет использовать синтаксис async/await, добавленный в Python 3.5. По этой причине код не блокируется и отличается скоростью выполнения. Sanic использует uvloop и ujson, когда нужно помочь с производительностью, однако данные пакеты являются опциональными.
Starlette является легким фреймворком ASGI, что идеален для создания высокопроизводительных сервисов asyncio. Он может использоваться как самостоятельный фреймворк, так и как инструментарий ASGI. Поставляется вкупе с обширным ассортиментом инструментов, поддерживает WebSockets, GraphQL, внутрипроцессовые фоновые задачи, а также текстовый клиент, построенный на Requests Python.
Masonite является веб-фреймворком Python, сконцетрированном на разработке. Он стремится соответствовать подходу «все включено». Это отличный инструментарий программиста с огромным количеством функционала и чрезвычайно растяжимой архитектурой.
FastAPI является современным, высокопроизводительным веб-фреймворком для создания API на Python 3.6+ основанный на подсказки типов Python. Создан поверх Starlette и является одним из самых быстрых и доступных фреймворков Python.
FastAPI базируется, а также является совместимым, с открытыми стандартами для API — OpenAPI (ранее известный как Swagger) и JSON Schema.
Responder также основан на Starlette. При создании Responder главной идеей было совместить лучшие аспекты Flask и Falcon внутри одного-единcтвенного фреймворка.
У него есть встроенный статический сервер для продакшена, автоматические gzip-ответы, нативная поддержка GraphQL и встроенный клиент для тестов, использующий модуль Requests.
Molten является минималистичным, расширяемым, быстрым и производительным фреймворком для создания HTTP API на Python. Molten автоматически проверяет запросы на соответствие с предопределенными схемами, гарантируя, что обработчики будут запускаться только при наличии правильного ввода.
Japronto является быстрым, масштабируемым, асинхронным HTTP инструментарием для Python 3.5+, интегрированным с конвейерным HTTP-сервером, базирующимся на uvloop и picohttpparser.
Он предназначен тех, кому важна скорость, внимательность к деталям и новые разработки. На данный момент нет особых новостей касательно разработки Japronto, однако о том, что проект заброшен, создатели также не сообщали.
Klein — это микро-фреймворк для разработки веб-сервисов на Python. Klein отличается минималистичным API, что похож на Bottle и Flask. Стоит отметить, что он зависим от дополнительных инструментов вне стандартной библиотеки.
Причина в том, что Klein создан на широко используемых и хорошо протестированных компонентах, таких как Werkzeug и Twisted.
Quart является Python ASGI веб-микрофреймворком. Он предназначен для того чтобы предоставить самый простой способ использования асинхронных функций в веб-контексте, особенно с уже существующими приложениями Flask.
Это становится возможным, благодаря тому, что Quart API является супер-набором для API Flask. Quart позиционирует себя в качестве полноценного веб-микрофреймворком. Он поддерживает HTTP/1.1, HTTP/2 и вебсокеты.
BlackShepp является асинхронным веб-фреймворком для создания веб-приложений Python, которые не блокируются и в основе которых лежат события. Вдохновлен Flask и ASP.NET Core.
BlackSheep поддерживает автоматическую связку значений с обработчиками запросов, задействуя аннотации типа или конвенции. Он также поддерживает внедрение зависимостей и имплементацию стратегий для обработки аутентификации и авторизации, используя внешние библиотеки.
Cyclone является веб-фреймворком, который реализует Tornado API в виде протокола Twisted. Идея в соединении элегантного и ясного Tornado API с циклами событий Twisted, что позволяет использовать огромное количество поддерживаемых протоколов.
Эта комбинация обеспечивает основу для создания гибридных серверов, способных очень эффективно обрабатывать HTTP, а также одновременно использовать электронную почту, ssh, sip, irc, причем одновременно.
Cyclone является веб-фреймворком, который реализует Tornado API в виде протокола Twisted. Идея в соединении элегантного и ясного Tornado API с циклами событий Twisted, что позволяет использовать огромное количество поддерживаемых протоколов.
Эта комбинация обеспечивает основу для создания гибридных серверов, способных очень эффективно обрабатывать HTTP, а также одновременно использовать электронную почту, ssh, sip, irc, причем одновременно.
Топ 5 библиотек python разработчика
5. Beautiful Soup
Beautiful Soup - это парсер для синтаксического разбора файлов HTML/XML, написанный на языке программирования Python, который может преобразовать даже неправильную разметку в дерево синтаксического разбора. Он поддерживает простые и естественные способы навигации, поиска и модификации дерева синтаксического разбора. В большинстве случаев он поможет программисту сэкономить часы и дни работы
4. Pillow
Python Imaging Library — библиотека языка Python, предназначенная для работы с растровой графикой. Разработка библиотеки прекращена. Однако проект под названием Pillow, являющийся форком PIL, развивается и включает, в том числе, поддержку Python 3.x
3. SQL Alchemy
SQLAlchemy — это программная библиотека на языке Python для работы с реляционными СУБД с применением технологии ORM. Служит для синхронизации объектов Python и записей реляционной базы данных. SQLAlchemy позволяет описывать структуры баз данных и способы взаимодействия с ними на языке Python без использования SQL.
2. Simplejson
Simplejson - это быстрый, точный и расширяемый json кодировщик и декодировщик, который поддерживает Python 3.3+ с обратной совместимостью с Python 2.5.
Simplejson написан на Python и не имеет внешних зависимостей. Он также включает расширения, написанные на С для представлений с особо высоким быстродействием. Помимо дефолтной UTF-8, декодер Simplejson может оперировать строками JSON, поступающими в любой кодировке.
1. Requests
Requests - это библиотека Python HTTP, выпущенная под лицензией Apache2. Цель проекта - сделать запросы HTTP проще и удобнее для человека
5. Beautiful Soup
Beautiful Soup - это парсер для синтаксического разбора файлов HTML/XML, написанный на языке программирования Python, который может преобразовать даже неправильную разметку в дерево синтаксического разбора. Он поддерживает простые и естественные способы навигации, поиска и модификации дерева синтаксического разбора. В большинстве случаев он поможет программисту сэкономить часы и дни работы
4. Pillow
Python Imaging Library — библиотека языка Python, предназначенная для работы с растровой графикой. Разработка библиотеки прекращена. Однако проект под названием Pillow, являющийся форком PIL, развивается и включает, в том числе, поддержку Python 3.x
3. SQL Alchemy
SQLAlchemy — это программная библиотека на языке Python для работы с реляционными СУБД с применением технологии ORM. Служит для синхронизации объектов Python и записей реляционной базы данных. SQLAlchemy позволяет описывать структуры баз данных и способы взаимодействия с ними на языке Python без использования SQL.
2. Simplejson
Simplejson - это быстрый, точный и расширяемый json кодировщик и декодировщик, который поддерживает Python 3.3+ с обратной совместимостью с Python 2.5.
Simplejson написан на Python и не имеет внешних зависимостей. Он также включает расширения, написанные на С для представлений с особо высоким быстродействием. Помимо дефолтной UTF-8, декодер Simplejson может оперировать строками JSON, поступающими в любой кодировке.
1. Requests
Requests - это библиотека Python HTTP, выпущенная под лицензией Apache2. Цель проекта - сделать запросы HTTP проще и удобнее для человека
SQL - инъекции, как защитить Django-проект?
https://zen.yandex.ru/media/id/5cbb4adabc785500b3b6b47b/sql-inekcii-kak-zascitit-djangoproekt-5cfa8d9a95ea7300af21bd3b
https://zen.yandex.ru/media/id/5cbb4adabc785500b3b6b47b/sql-inekcii-kak-zascitit-djangoproekt-5cfa8d9a95ea7300af21bd3b
Яндекс Дзен
SQL - инъекции, как защитить Django-проект?
«Мы не должны просить наших пользователей, чтобы они сделали выбор между безопасностью и приватностью. Мы должны просто предложить им лучшее, что доступно в обеих этих областях. В конце концов, защита чьих-то данных — защита всех нас». Тим Кук Инъекция SQL…
import bugfeature as 🤖
Как вам такой способ импорта в питоне с использованием эмодзи? Некоторым разработчикам понравилась эта идея и они создали библиотеку pythonji.
При помощи её, можно писать код с использованием смайликов. Например в качестве счетчика лайков указать ❤, а для дизлайков воспользоваться 💩.
Забавно, что расширение у файлов библиотеки - 🐍. Исходники доступны на GitHub (https://github.com/gahjelle/pythonji), а установить её можно командой:
python -m pip install pythonji
Как вам такой способ импорта в питоне с использованием эмодзи? Некоторым разработчикам понравилась эта идея и они создали библиотеку pythonji.
При помощи её, можно писать код с использованием смайликов. Например в качестве счетчика лайков указать ❤, а для дизлайков воспользоваться 💩.
Забавно, что расширение у файлов библиотеки - 🐍. Исходники доступны на GitHub (https://github.com/gahjelle/pythonji), а установить её можно командой:
python -m pip install pythonji
А я тем временем продолжаю писать туториалы по django фреймворку. Ребят поддержите автора донатом, на развитие канала
5599005004199621
👍👍👍
https://zen.yandex.ru/media/id/5cbb4adabc785500b3b6b47b/django-tutorial-part-3-privet-mir-localhost-5de1421d3d008800ad7b4e83
5599005004199621
👍👍👍
https://zen.yandex.ru/media/id/5cbb4adabc785500b3b6b47b/django-tutorial-part-3-privet-mir-localhost-5de1421d3d008800ad7b4e83
Яндекс Дзен
Django tutorial: part 3 - Привет мир (localhost)
В этой статье мы будем строго придерживаться одного правила, оно известно, о нем я уже писал, и напишу еще отдельную статью на примерах с django. Сейчас же нам необходимо запомнить три файла:
Создание приложения Python Flask с помощью Docker на Azure
https://morioh.com/p/c47848b1732c?f=5c21fb01c16e2556b555ab32
https://morioh.com/p/c47848b1732c?f=5c21fb01c16e2556b555ab32
Morioh
Building a Python Flask application with Docker on Azure
In this video, you will guide you to build a Python Flask application with Docker, Azure Container Registry and Azure App Services.
После полутора лет разработки вышел Python 3.8
Среди обновлений:
● добавлен новый оператор присваивания :=. Он не заменяет стандартную операцию. С ним можно присваивать значения внутри других выражений, избегая двойного вызова функций в условных операторах и циклах.
● добавлен API для C. Он позволяет настраивать параметры инициализации Python. Это упростит встраивание функциональности Python в приложения на C.
● новый синтаксис для задания аргументов функции. Признак / отделяет аргументы, которым присваивать значения можно только в порядке перечисления, от аргументов, которые поддерживают произвольное присваивание.
● по умолчанию поставлен протокол Pickle 4. Он гораздо производительнее третьей версии и лучше сокращает размер данных.
● новое в модуле typing 3: класс TypedDict для ассоциативных массивов, тип Literal для ограничения параметров и конструкция Final для определения значения функций и переменных, которые нельзя изменять и переназначать.
Новую ветку будут поддерживать ещё полтора года, а доставлять патчи от уязвимостей — до 2024 года. Первое корректирующее обновление выпустят в декабре, остальные — раз в два месяца.
Среди обновлений:
● добавлен новый оператор присваивания :=. Он не заменяет стандартную операцию. С ним можно присваивать значения внутри других выражений, избегая двойного вызова функций в условных операторах и циклах.
● добавлен API для C. Он позволяет настраивать параметры инициализации Python. Это упростит встраивание функциональности Python в приложения на C.
● новый синтаксис для задания аргументов функции. Признак / отделяет аргументы, которым присваивать значения можно только в порядке перечисления, от аргументов, которые поддерживают произвольное присваивание.
● по умолчанию поставлен протокол Pickle 4. Он гораздо производительнее третьей версии и лучше сокращает размер данных.
● новое в модуле typing 3: класс TypedDict для ассоциативных массивов, тип Literal для ограничения параметров и конструкция Final для определения значения функций и переменных, которые нельзя изменять и переназначать.
Новую ветку будут поддерживать ещё полтора года, а доставлять патчи от уязвимостей — до 2024 года. Первое корректирующее обновление выпустят в декабре, остальные — раз в два месяца.
Проверка на None
None не является уникальным объектом в Python. Он имеет аналоги, например, null в C-подобных языках.
Можно проверить, ссылается ли переменная на None с помощью операторов сравнения == и !=:
Однако, предпочтительнее использование is и is not:
Кроме того, лучше использовать конструкцию x is not None, а не менее читабельную альтернативу (x is None).
None не является уникальным объектом в Python. Он имеет аналоги, например, null в C-подобных языках.
Можно проверить, ссылается ли переменная на None с помощью операторов сравнения == и !=:
>>> x, y = 2, None
>>> x == None
False
>>> y == None
True
>>> x != None
True
>>> y != None
False
Однако, предпочтительнее использование is и is not:
>>> x is None
False
>>> y is None
True
>>> x is not None
True
>>> y is not None
False
Кроме того, лучше использовать конструкцию x is not None, а не менее читабельную альтернативу (x is None).
Введение Python filter () Функция с примерами
https://morioh.com/p/93a8e1a873a9?f=5c21fb01c16e2556b555ab32
https://morioh.com/p/93a8e1a873a9?f=5c21fb01c16e2556b555ab32
Morioh
Introduction Python filter() Function with Examples
The filter() function takes a function and a sequence as arguments and returns an iterable, only yielding the items in sequence for which function returns True. If None is passed instead of a function, all the items of the sequence which evaluates to False…
@sysodmins_league - Канал, посвященный специалистам сферы ИТ, занимающимся поддержкой сетевой и серверной инфраструктуры, технической поддержкой пользователей, а так же всем тем, кто им сочувствует и понимает.
Здесь вы найдете множество best practice, how-to, новости мира ИТ, литературу и многое другое.
Здесь вы найдете множество best practice, how-to, новости мира ИТ, литературу и многое другое.
Global Interpreter Lock (GIL) — это способ синхронизации потоков, который используется в некоторых интерпретируемых языках программирования, например в Python и Ruby.
GIL является самым простым способом избежать конфликтов при одновременном обращении разных потоков к одним и тем же участкам памяти. Когда один поток захватывает его, GIL, работая по принципу мьютекса, блокирует остальные. Нет параллельных потоков — нет конфликтов при обращении к разделяемым объектам. Очерёдность выполнения потоков определяет интерпретатор в зависимости от реализации, переключение между потоками может происходить: когда активный поток пытается осуществить ввод-вывод, по исчерпании лимита выполненных инструкций либо по таймеру.
Главный недостаток подхода обеспечения потокобезопасности при помощи GIL — это ограничение параллельности вычислений. GIL не позволяет достигать наибольшей эффективности вычислений при работе на многоядерных и мультипроцессорных системах. Также использование нескольких потоков накладывает издержки на их переключение из-за эффекта конкуренции (потоки «пытаются» перехватить GIL). То есть многопоточное выполнение может занять большее время, чем последовательное выполнение тех же задач.
Причины использования GIL:
Однопоточные сценарии выполняются значительно быстрее, чем при использовании других подходов обеспечения потокобезопасности;
Простая интеграция библиотек на C, которые зачастую тоже не потокобезопасны;
Простота реализации.
GIL используется в CPython'е, наиболее распространённой реализации интерпретатора языка Python , и в Ruby MRI, эталонной реализации интерпретатора языка Ruby, где он зовётся Global VM Lock.
В сети не раз появлялись петиции и открытые письма с просьбой убрать GIL из Python'а. Однако создатель и «великодушный пожизненный диктатор» проекта Гвидо ван Россум заявляет, что GIL не так уж и плох и он будет в CPython'е до тех пор, пока кто-то другой не представит реализацию Python'а без GIL, с которой бы однопоточные скрипты работали так же быстро.
Реализации интерпретаторов на JVM (Jython, JRuby) и на .NET (IronPython, IronRuby) не используют GIL.
В рамках проекта PyPy ведётся работа по реализации транзакционной памяти (англ. Software Transactional Memory, SТМ). На данный момент даже в многопоточных вычислениях интерпретатор с STM работает во много раз медленней, чем с GIL. Но за счёт JIT PyPy-STM всё равно быстрее, чем CPython.
GIL является самым простым способом избежать конфликтов при одновременном обращении разных потоков к одним и тем же участкам памяти. Когда один поток захватывает его, GIL, работая по принципу мьютекса, блокирует остальные. Нет параллельных потоков — нет конфликтов при обращении к разделяемым объектам. Очерёдность выполнения потоков определяет интерпретатор в зависимости от реализации, переключение между потоками может происходить: когда активный поток пытается осуществить ввод-вывод, по исчерпании лимита выполненных инструкций либо по таймеру.
Главный недостаток подхода обеспечения потокобезопасности при помощи GIL — это ограничение параллельности вычислений. GIL не позволяет достигать наибольшей эффективности вычислений при работе на многоядерных и мультипроцессорных системах. Также использование нескольких потоков накладывает издержки на их переключение из-за эффекта конкуренции (потоки «пытаются» перехватить GIL). То есть многопоточное выполнение может занять большее время, чем последовательное выполнение тех же задач.
Причины использования GIL:
Однопоточные сценарии выполняются значительно быстрее, чем при использовании других подходов обеспечения потокобезопасности;
Простая интеграция библиотек на C, которые зачастую тоже не потокобезопасны;
Простота реализации.
GIL используется в CPython'е, наиболее распространённой реализации интерпретатора языка Python , и в Ruby MRI, эталонной реализации интерпретатора языка Ruby, где он зовётся Global VM Lock.
В сети не раз появлялись петиции и открытые письма с просьбой убрать GIL из Python'а. Однако создатель и «великодушный пожизненный диктатор» проекта Гвидо ван Россум заявляет, что GIL не так уж и плох и он будет в CPython'е до тех пор, пока кто-то другой не представит реализацию Python'а без GIL, с которой бы однопоточные скрипты работали так же быстро.
Реализации интерпретаторов на JVM (Jython, JRuby) и на .NET (IronPython, IronRuby) не используют GIL.
В рамках проекта PyPy ведётся работа по реализации транзакционной памяти (англ. Software Transactional Memory, SТМ). На данный момент даже в многопоточных вычислениях интерпретатор с STM работает во много раз медленней, чем с GIL. Но за счёт JIT PyPy-STM всё равно быстрее, чем CPython.
В Python есть одна проблема: есть глобальная блокировка интерпретатора, которая не позволяет двум потокам в одном и том же процессе одновременно запускать код Python. Это означает, что если у вас 8 ядер и вы измените код на использование 8 потоков, он не сможет использовать 800% ЦП и работать в 8 раз быстрее; он будет использовать тот же 100% процессор и работать с той же скоростью. (На самом деле, он будет работать немного медленнее, потому что при многопоточности возникают дополнительные издержки, даже если у вас нет общих данных, но пока игнорируйте это.)
Есть исключения из этого. Если тяжелые вычисления в вашем коде на самом деле не происходят в Python, но в какой-то библиотеке с пользовательским кодом C, которая выполняет правильную обработку GIL, например, в numpy-приложении, вы получите ожидаемый выигрыш в производительности от потоков. То же самое верно, если тяжелые вычисления выполняются каким-то подпроцессом, который вы запускаете и ждете.
Что еще более важно, есть случаи, когда это не имеет значения. Например, сетевой сервер тратит большую часть своего времени на чтение пакетов из сети, а приложение с графическим интерфейсом тратит большую часть своего времени на ожидание пользовательских событий. Одна из причин использования потоков в сетевом сервере или приложении с графическим интерфейсом - это возможность выполнять длительные «фоновые задачи», не останавливая основной поток от продолжения обслуживания сетевых пакетов или событий графического интерфейса. И это прекрасно работает с потоками Python. (С технической точки зрения это означает, что потоки Python обеспечивают параллелизм, даже если они не обеспечивают параллелизма ядра.)
Но если вы пишете программу с привязкой к процессору на чистом Python, использование большего количества потоков обычно не помогает.
Использование отдельных процессов не имеет таких проблем с GIL, потому что каждый процесс имеет свой отдельный GIL. Конечно, между потоками и процессами у вас все еще есть те же компромиссы, что и в любых других языках - разделять данные между процессами труднее и дороже, чем между потоками, может быть дорого запускать огромное количество процессов или создавать и уничтожать их часто и т. д. Но GIL сильно влияет на баланс между процессами, и это не так, скажем, для C или Java. Таким образом, вы обнаружите, что используете многопроцессорность гораздо чаще в Python, чем в C или Java.
Между тем, философия Python «включенные батареи» приносит некоторые хорошие новости: очень легко писать код, который можно переключать между потоками и процессами с помощью смены одной строки.
Если вы разрабатываете свой код в терминах автономных «заданий», которые ничего не делят с другими заданиями (или основной программой), кроме ввода и вывода, вы можете использовать concurrent.futures библиотеку для написания кода вокруг пула потоков, например:
Вы даже можете получить результаты этих заданий и передать их на дальнейшие задания, ждать, пока все будет в порядке выполнения или в порядке завершения и т. Д .; прочитайте раздел об Futureобъектах для деталей.
Теперь, если окажется, что ваша программа постоянно использует 100% ЦП, а добавление большего количества потоков просто замедляет ее, то вы столкнулись с проблемой GIL, поэтому вам нужно переключиться на процессы. Все, что вам нужно сделать, это изменить эту первую строку:
Единственное реальное предостережение в том, что аргументы и возвращаемые значения ваших заданий должны быть легко перестраиваемыми (и не требовать слишком много времени или памяти для перебора), чтобы их можно было использовать в перекрестном процессе. Обычно это не проблема, но иногда это так.
Но что, если ваша работа не может быть самостоятельной?
Есть исключения из этого. Если тяжелые вычисления в вашем коде на самом деле не происходят в Python, но в какой-то библиотеке с пользовательским кодом C, которая выполняет правильную обработку GIL, например, в numpy-приложении, вы получите ожидаемый выигрыш в производительности от потоков. То же самое верно, если тяжелые вычисления выполняются каким-то подпроцессом, который вы запускаете и ждете.
Что еще более важно, есть случаи, когда это не имеет значения. Например, сетевой сервер тратит большую часть своего времени на чтение пакетов из сети, а приложение с графическим интерфейсом тратит большую часть своего времени на ожидание пользовательских событий. Одна из причин использования потоков в сетевом сервере или приложении с графическим интерфейсом - это возможность выполнять длительные «фоновые задачи», не останавливая основной поток от продолжения обслуживания сетевых пакетов или событий графического интерфейса. И это прекрасно работает с потоками Python. (С технической точки зрения это означает, что потоки Python обеспечивают параллелизм, даже если они не обеспечивают параллелизма ядра.)
Но если вы пишете программу с привязкой к процессору на чистом Python, использование большего количества потоков обычно не помогает.
Использование отдельных процессов не имеет таких проблем с GIL, потому что каждый процесс имеет свой отдельный GIL. Конечно, между потоками и процессами у вас все еще есть те же компромиссы, что и в любых других языках - разделять данные между процессами труднее и дороже, чем между потоками, может быть дорого запускать огромное количество процессов или создавать и уничтожать их часто и т. д. Но GIL сильно влияет на баланс между процессами, и это не так, скажем, для C или Java. Таким образом, вы обнаружите, что используете многопроцессорность гораздо чаще в Python, чем в C или Java.
Между тем, философия Python «включенные батареи» приносит некоторые хорошие новости: очень легко писать код, который можно переключать между потоками и процессами с помощью смены одной строки.
Если вы разрабатываете свой код в терминах автономных «заданий», которые ничего не делят с другими заданиями (или основной программой), кроме ввода и вывода, вы можете использовать concurrent.futures библиотеку для написания кода вокруг пула потоков, например:
with
concurrent.futures.ThreadPoolExecutor(max_workers=4) as executor: executor.submit(job, argument) executor.map(some_function, collection_of_independent_things)
# ...Вы даже можете получить результаты этих заданий и передать их на дальнейшие задания, ждать, пока все будет в порядке выполнения или в порядке завершения и т. Д .; прочитайте раздел об Futureобъектах для деталей.
Теперь, если окажется, что ваша программа постоянно использует 100% ЦП, а добавление большего количества потоков просто замедляет ее, то вы столкнулись с проблемой GIL, поэтому вам нужно переключиться на процессы. Все, что вам нужно сделать, это изменить эту первую строку:
with concurrent.futures.ProcessPoolExecutor(max_workers=4) as executorЕдинственное реальное предостережение в том, что аргументы и возвращаемые значения ваших заданий должны быть легко перестраиваемыми (и не требовать слишком много времени или памяти для перебора), чтобы их можно было использовать в перекрестном процессе. Обычно это не проблема, но иногда это так.
Но что, если ваша работа не может быть самостоятельной?
Если вы можете разработать свой код с точки зрения заданий, которые передают сообщения от одного к другому, это все еще довольно легко. Возможно, вам придется использовать threading.Threadили multiprocessing.Processвместо того, чтобы полагаться на пулы. И вам придется создавать объекты queue.Queueили multiprocessing.Queueявно. (Существует множество других опций - каналы, сокеты, файлы со скоплениями, ... но дело в том, что вы должны сделать что-то вручную, если автоматическая магия исполнителя недостаточна.)
Но что, если вы даже не можете положиться на передачу сообщений? Что делать, если вам нужно две работы, чтобы изменить одну и ту же структуру и увидеть изменения друг друга? В этом случае вам нужно будет выполнить ручную синхронизацию (блокировки, семафоры, условия и т. Д.) И, если вы хотите использовать процессы, явные объекты совместной памяти для загрузки. Это когда многопоточность (или многопроцессорность) становится сложной. И если вы можете избежать этого, то это прекрасно.
Но что, если вы даже не можете положиться на передачу сообщений? Что делать, если вам нужно две работы, чтобы изменить одну и ту же структуру и увидеть изменения друг друга? В этом случае вам нужно будет выполнить ручную синхронизацию (блокировки, семафоры, условия и т. Д.) И, если вы хотите использовать процессы, явные объекты совместной памяти для загрузки. Это когда многопоточность (или многопроцессорность) становится сложной. И если вы можете избежать этого, то это прекрасно.