А я тем временем продолжаю писать туториалы по 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явно. (Существует множество других опций - каналы, сокеты, файлы со скоплениями, ... но дело в том, что вы должны сделать что-то вручную, если автоматическая магия исполнителя недостаточна.)
Но что, если вы даже не можете положиться на передачу сообщений? Что делать, если вам нужно две работы, чтобы изменить одну и ту же структуру и увидеть изменения друг друга? В этом случае вам нужно будет выполнить ручную синхронизацию (блокировки, семафоры, условия и т. Д.) И, если вы хотите использовать процессы, явные объекты совместной памяти для загрузки. Это когда многопоточность (или многопроцессорность) становится сложной. И если вы можете избежать этого, то это прекрасно.
Но что, если вы даже не можете положиться на передачу сообщений? Что делать, если вам нужно две работы, чтобы изменить одну и ту же структуру и увидеть изменения друг друга? В этом случае вам нужно будет выполнить ручную синхронизацию (блокировки, семафоры, условия и т. Д.) И, если вы хотите использовать процессы, явные объекты совместной памяти для загрузки. Это когда многопоточность (или многопроцессорность) становится сложной. И если вы можете избежать этого, то это прекрасно.
В чем разница между потоком и процессом?
Процессы и потоки связаны друг с другом, но при этом имеют существенные различия.
Процесс — экземпляр программы во время выполнения, независимый объект, которому выделены системные ресурсы (например, процессорное время и память). Каждый процесс выполняется в отдельном адресном пространстве: один процесс не может получить доступ к переменным и структурам данных другого. Если процесс хочет получить доступ к чужим ресурсам, необходимо использовать межпроцессное взаимодействие. Это могут быть конвейеры, файлы, каналы связи между компьютерами и многое другое.
Поток использует то же самое пространства стека, что и процесс, а множество потоков совместно используют данные своих состояний. Как правило, каждый поток может работать (читать и писать) с одной и той же областью памяти, в отличие от процессов, которые не могут просто так получить доступ к памяти другого процесса. У каждого потока есть собственные регистры и собственный стек, но другие потоки могут их использовать.
Поток — определенный способ выполнения процесса. Когда один поток изменяет ресурс процесса, это изменение сразу же становится видно другим потокам этого процесса.
Процессы и потоки связаны друг с другом, но при этом имеют существенные различия.
Процесс — экземпляр программы во время выполнения, независимый объект, которому выделены системные ресурсы (например, процессорное время и память). Каждый процесс выполняется в отдельном адресном пространстве: один процесс не может получить доступ к переменным и структурам данных другого. Если процесс хочет получить доступ к чужим ресурсам, необходимо использовать межпроцессное взаимодействие. Это могут быть конвейеры, файлы, каналы связи между компьютерами и многое другое.
Поток использует то же самое пространства стека, что и процесс, а множество потоков совместно используют данные своих состояний. Как правило, каждый поток может работать (читать и писать) с одной и той же областью памяти, в отличие от процессов, которые не могут просто так получить доступ к памяти другого процесса. У каждого потока есть собственные регистры и собственный стек, но другие потоки могут их использовать.
Поток — определенный способ выполнения процесса. Когда один поток изменяет ресурс процесса, это изменение сразу же становится видно другим потокам этого процесса.
Учебник по Python: создание веб-приложения для опроса Discord с помощью Python
https://morioh.com/p/27207a7ebe8e?f=5c21fb01c16e2556b555ab32
https://morioh.com/p/27207a7ebe8e?f=5c21fb01c16e2556b555ab32
Morioh
Python Tutorial : How to Making a Discord polling web app with Python
After-hours coding session, making a polling web app with Python that uses Discord API for authentication.