как узнать память работы кода питон
Определить свободную оперативную память в Python
Я хотел бы, чтобы мой скрипт на Python использовал всю доступную оперативную память, но не более (по соображениям эффективности). Я могу контролировать это, считывая только ограниченный объем данных, но мне нужно знать, сколько ОЗУ свободно во время выполнения, чтобы получить это право. Он будет работать на различных системах Linux. Можно ли определить свободную оперативную память во время выполнения?
5 ответов
Также лучше, если вы не пытаетесь перехитрить управление памятью вашей ОС. Это обычно заканчивается слезами (или медленными программами). Лучше просто возьми оперативную память, которая тебе нужна. Если вы хотите использовать как можно больше на компьютере с ранее неизвестным объемом памяти, я бы, вероятно, проверил, сколько ОЗУ установлено ( MemTotal в /proc/meminfo ), оставьте определенное количество для ОС и в качестве запаса прочности (скажем, 1 ГБ) и использовать остальное.
В системах Linux я время от времени использую это:
Вы можете запустить это, когда ваш скрипт запускается. ОЗУ обычно используется и освобождается довольно часто в загруженной системе, поэтому вы должны принять это во внимание, прежде чем решить, какой объем ОЗУ использовать. Кроме того, большинство систем Linux имеют значение подкачки 60. При использовании памяти, страницы, которые используются реже всего, будут заменены. Вы можете использовать SWAP вместо RAM.
Надеюсь это поможет.
Я полагаю, вы могли бы использовать бесплатно (http: / /www.cyberciti.biz/faq/linux-check-memory-usage/), ps или, возможно, класс MemoryMonitor из SO-потока, размещенного на в самом низу моего ответа, чтобы сделать это. Просто уменьшите провисание и оставьте небольшое количество оперативной памяти неиспользованным для других процессов, если им это необходимо срочно, чтобы избежать записи на диск от их имени.
Вам нужно будет проанализировать вывод из free или ps, если вы используете это, но это не должно быть сложно. Помните, что вам нужно анализировать доступную оперативную память в режиме реального времени, чтобы вы могли настроить, если другой процесс по какой-то причине становится голодным.
Согласно документации поле available «рассчитывается суммируя различные значения памяти в зависимости от платформы, и предполагается, что она будет использоваться для мониторинга фактического использования памяти кроссплатформенным способом. «
Обратите внимание, что возвращаемое значение будет в байтах
Как узнать текущее использование процессора и оперативной памяти в Python?
Какой предпочитаемый способ получения текущего состояния системы (текущий процессор, оперативная память, свободное место на диске и т. Д.) В Python? Бонусные баллы для * nix и Windows платформ.
Кажется, есть несколько возможных способов извлечь это из моего поиска:
Использование библиотеки, такой как PSI (которая в настоящее время, кажется, не активно развивается и не поддерживается на нескольких платформах) или что-то вроде pystatgrab (опять же, с 2007 года, похоже, нет активности и нет поддержки Windows)
Использование специфического для платформы кода, например использование os.popen(«ps») или аналогичный для систем * nix и MEMORYSTATUS в ctypes.windll.kernel32 (см. Этот рецепт на ActiveState ) для платформы Windows. Можно поместить класс Python вместе со всеми этими фрагментами кода.
Не то чтобы эти методы плохие, но уже есть хорошо поддерживаемый, многоплатформенный способ сделать то же самое?
Библиотека psutil предоставляет вам информацию о процессоре, оперативной памяти и т. Д. На различных платформах:
В настоящее время он поддерживает Linux, Windows, OSX, Sun Solaris, FreeBSD, OpenBSD и NetBSD, как 32-разрядные, так и 64-разрядные архитектуры, с версиями Python от 2.6 до 3.5 (пользователи Python 2.4 и 2.5 могут использовать версию 2.1.3).
Вот другая документация, которая предоставляет больше понятий и понятий интереса:
Чтобы получить статистику по памяти и процессору:
У virtual_memory (кортежа) будет процент памяти, используемой в масштабе всей системы. Это казалось мне завышенным на несколько процентов в Ubuntu 18.04.
Вы также можете получить память, используемую текущим экземпляром Python:
который дает текущее использование памяти вашего скрипта Python.
Только для Linux: одна строка для использования ОЗУ с зависимостью только от stdlib:
редактировать: указанное решение ОС зависимости
У меня ниже коды, без внешних библиотек работали. Я тестировал на Python 2.7.9
Использование процессора
И использование плунжера, всего, б / у и бесплатно
Вот кое-что, что я собрал некоторое время назад, это только окна, но может помочь вам получить часть того, что вам нужно сделать.
Мы решили использовать обычный источник информации для этого, потому что мы могли найти мгновенные колебания в свободной памяти и чувствовали, что запрос источника данных meminfo был полезен. Это также помогло нам получить еще несколько связанных параметров, которые были предварительно проанализированы.
Вывод для справки (мы удалили все новые строки для дальнейшего анализа)
MemTotal: 1014500 кБ MemFree: 562680 кБ MemAvailable: 646364 кБ Буферы: 15144 кБ Кэшированные: 210720 КБ Свопы: 0 КБ Активные: 261476 КБ Неактивные: 128888 КБ Активные (анон): 167092 КБ Неактивные (анон): файл 20888 КБ Активные (файл) : 94384 КБ Неактивен (файл): 108000 КБ Неуязвим: 3652 КБ Блокировано: 3652 КБ Общий обмен: 0 КБ Свободный обмен: 0 КБ Грязный: 0 КБ Обратная запись: 0 КБ Количество страниц: 168160 КБ Отображено: 81352 КБ Shmem: 21060 КБ Плита: 34492 Объясняемое: 18044 кБ. SUВозвратное: 16448 кБ. Ядро: стек: 2672 кБ. Параметры таблицы: 8180 кБ. NFS_Unstable: 0 КБ. Отказов: 0 КБ. 0 КБ2048 КБ DirectMap4k: 43008 КБ DirectMap2M: 1005568 КБ
Как узнать текущее использование процессора и оперативной памяти в Python?
Какой предпочитаемый способ получения текущего состояния системы (текущий процессор, оперативная память, свободное место на диске и т. Д.) В Python? Бонусные баллы для * nix и Windows платформ.
Кажется, есть несколько возможных способов извлечь это из моего поиска:
Использование библиотеки, такой как PSI (которая в настоящее время, кажется, не активно развивается и не поддерживается на нескольких платформах) или что-то вроде pystatgrab (опять нет активности с 2007 года, как кажется и нет поддержки Windows).
Использование специального кода платформы, например, os.popen(«ps») или аналогичного для систем * nix и MEMORYSTATUS в ctypes.windll.kernel32 (см. этот рецепт на ActiveState ) для платформы Windows. Можно поместить класс Python вместе со всеми этими фрагментами кода.
Не то чтобы эти методы плохие, но уже существует хорошо поддерживаемый, многоплатформенный способ сделать то же самое?
12 ответов
Библиотека psutil предоставит вам некоторую системную информацию (использование ЦП / памяти) на различных платформах:
В настоящее время он поддерживает Linux, Windows, OSX, Sun Solaris, FreeBSD, OpenBSD и NetBSD, как 32-разрядные, так и 64-разрядные архитектуры, с версиями Python от 2.6 до 3.5 (пользователи Python 2.4 и 2.5 могут использовать версию 2.1.3).
ОБНОВЛЕНИЕ: Вот несколько примеров использования psutil :
Вот кое-что, что я собрал некоторое время назад, это только окна, но может помочь вам получить часть того, что вам нужно сделать.
Этот скрипт для использования процессора:
Основываясь на коде использования процессора @Hrabal, я использую это:
Я чувствую, что эти ответы были написаны для Python 2, и в любом случае никто не упомянул стандарт resource пакет, который доступен для Python 3. Он предоставляет команды для получения ресурса limit для данного процесса (вызывающий процесс Python по умолчанию). Это не то же самое, что получение текущего использования ресурсов системой в целом, но это может решить некоторые из тех же проблем, например, например, «Я хочу убедиться, что я использую только X много оперативной памяти с этим сценарием».
Вывод для справки (мы удалили все новые строки для дальнейшего анализа)
MemTotal: 1014500 кБ MemFree: 562680 кБ MemAvailable: 646364 кБ Буферы: 15144 кБ Кэшированные: 210720 КБ Свопинговые: 0 КБ Активные: 261476 КБ Неактивные: 128888 КБ Активные (анон): 167092 КБ Неактивные (анон): файл 20888 КБ Активные (файл) : 94384 КБ Неактивен (файл): 108000 КБ Неуязвим: 3652 КБ Блокировано: 3652 КБ Общий обмен: 0 КБ Свободный обмен: 0 КБ Грязный: 0 КБ Обратная запись: 0 КБ Количество страниц: 168160 КБ Отображено: 81352 КБ Shmem: 21060 КБ Плита: 34492 SRExlaimable: 18044 кБ 0 кБ AnonHugePages: 88064 кБ CmaTotal: 0 кБ CmaFree: 0 кБ HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Огромный размер страницы: 2048 кБ DirectMap4k: 43008 КБ 10055 КБММ682
У меня ниже коды, без внешних библиотек работали. Я тестировал на Python 2.7.9
Загрузка процессора
Использование плунжера, общее, использованное и бесплатное
«. текущее состояние системы (текущий процессор, оперативная память, свободное место на диске и т. д.)» И «* nix и платформы Windows» могут оказаться трудной комбинацией.
«Свободное место на диске»? Что считается «дисковым пространством»? Все разделы всех устройств? А как насчет внешних разделов в мультизагрузочной среде?
Я не думаю, что существует достаточно четкий консенсус между Windows и * nix, который делает это возможным. Действительно, между различными операционными системами, называемыми Windows, может и не быть единого мнения. Есть ли один Windows API, который работает как для XP, так и для Vista?
Я не верю, что есть хорошо поддерживаемая многоплатформенная библиотека. Помните, что сам Python написан на C, поэтому любая библиотека просто примет умное решение о том, какой фрагмент кода для конкретной ОС запускать, как вы предложили выше.
Используйте библиотеку psutil. На Ubuntu 18.04 pip установлен 5.5.0 (последняя версия) по состоянию на 1-30-2019. Старые версии могут вести себя несколько иначе. Вы можете проверить свою версию psutil, выполнив это в Python:
Чтобы получить статистику по памяти и процессору:
virtual_memory (кортеж) будет иметь процент использования памяти в масштабе всей системы. Это казалось мне завышенным на несколько процентов в Ubuntu 18.04.
Вы также можете получить память, используемую текущим экземпляром Python:
Который дает текущее использование памяти вашего скрипта Python.
На странице pypi для psutil есть еще несколько подробных примеров.
Только для Linux: одна строка для использования ОЗУ с зависимостью только от stdlib:
Редактировать: указанное решение ОС зависимости
Вы можете использовать psutil или psmem с примером кода подпроцесса
Записки программиста
Тест производительности скриптов на Python
Если вы давно читаете мой блог, то можете помнить, как пару раз я говорил о Python разные неприятные вещи, дескать он медленный и памяти много кушает. При этом даже приводились различные пруфлинки. Но, откровенно говоря, нехорошо судить о языке по тому, массивы какой вложенности он поддерживает, с какой скоростью он выполняет пустой цикл из 100500 итераций и тд. Нас же интересует, как он справляется с типовыми задачами. Так что я решил провести собственный небольшой эксперимент.
1. Что и как будем измерять?
Меня в первую очередь интересуют две вещи — скорость скриптов и сколько они едят памяти. Формально говоря, сам по себе язык лишь косвенно влияет на скорость написанных с его помощью программ, или то, сколько памяти они потребляют. Но, повторюсь, нас интересуют типовые случаи. А какой интерпретатор обычно используют программисты на Python? Правильно, CPython. Вот его и будем тестировать.
Тест должен быть объективным. С одной стороны, нужно избавиться от всех возможных побочных эффектов — работы с сетью, обхода файловой системы, включенных торрентов и тп. С другой стороны, пример не должен получиться искусственным. К счастью, имеется типичная задача, которая традиционно решается с помощью скриптов и удовлетворяет обоим критериям. Это — парсинг большого файла с помощью регулярных выражений. И только попробуйте сказать, что это — нетипичная задача. Она охрененно типичная!
И последнее. Допустим, замерили мы скорость работы программы, она равна X. Это много или мало? Смотря с чем сравнивать! Сравнивать Python-скрипты будем с программами на С++ и скриптами на Perl (todo: в следующий раз не забыть про PHP). Тестировать все будем в следующем окружении:
2. Замеряем время выполнения
Где взять большой файл, чтобы пропарсить его? Я использовал слитый из кэша Google дамп некогда известного, а нынче закрывшегося форума. Спасти удалось не все, но для наших нужд — достаточно. После объединения всех сохраненных страниц в один файл, получилось около 300 Мб HTML-кода. Сверх сложную задачу ставить нет смысла, так что попробуем просто извлечь все ник-неймы форумчан.
#!/usr/bin/env python
import sys
import re
Здесь я не случайно использую конструкцию «for line in sys.stdin» вместо открытия файла и дальнейшего чтения из него. Как выяснилось, второй вариант работает ощутимо медленней. Следовательно, имеет место некий побочный эффект, а мы договорились их избегать.
Аналогичный скрипт, использующий предварительную компиляцию регулярного выражения:
#!/usr/bin/env python
import sys
import re
Авторы книги Python в системном администрировании UNIX и Linux утверждают, что второй скрипт должен работать быстрее первого. Проверим!
#!/usr/bin/env perl
use strict ;
Код программы на C++ можно получить путем внесения элементарных изменений в код из следующего пункта, так что здесь его я не привожу.
С Cython чуточку сложнее. Сначала получаем код на Си:
Дальше можно попытаться его скомпилировать:
Вот только это не будет работать. Полезут ошибки:
#ifdef __FreeBSD__
fp_except_t m ;
m = fpgetmask ( ) ;
fpsetmask ( m &
Проблема в том, что другая переменная с именем m объявлена несколькими строками выше. Так что вторую m нужно переименовать, после чего программа успешно соберется.
Все готово, теперь можно замерять время. В юниксах для этой цели традиционно используется утилита time (не путать со одноименной командой в bash!):
Строго говоря, здесь замеряется время работы утилиты cat, а не нашего скрипта. Это несложно проверить, дописав в конец скрипта команду «sleep(5)». Но передать имя входного файла в качестве аргумента мы не можем в связи с описанной выше особенностью Пайтона. Условия должны быть одинаковыми для всех испытуемых!
Можно было бы использовать команду типа:
… но тогда какую-то погрешность внесет утилита sh. К счастью, экспериментальным путем несложно проверить, что замеры с использованием и без использования sh дают практически идентичные результаты.
Все! Хватит теории. Давайте посмотрим на цифры:
Как и следовало ожидать, быстрее всего с задачей справилась программа на C++ (я назвал ее boost). За ней с небольшим отрывом идет скрипт на Perl. А вот скрипт на Пайтоне (python.py) оказался в целых 4 раза медленней скрипта на Perl!
Что удивительно, предварительная компиляция регулярного выражения (программы с «comp_re» в имени) лишь замедляет работу скрипта. С чем это связано — не знаю. Так или иначе, товарищи Ноа Гифт и Джереми М.Джонс на этот счет нас обманули. Как и на счет того, что Python прост в изучении и интуитивно понятен даже тем, кто никогда на нем не писал. Я недавно начал на нем писать, так что можете мне поверить.
Предварительная компиляция скрипта не ускоряет его выполнения. Ну это понятно — скрипты небольшие, так что их преобразование из текста во внутреннее представление интерпретатора и так проходит быстро. Хоть не замедляет — и на том спасибо 🙂
А вот что вызвало у меня настоящий шок — это скорость программ, полученных при помощи Cython (имена начинаются с «c_python»). Я не знаю, почему они такие медленные. Возможно, в libpython предусмотрены какие-то дополнительные проверки входных параметров, приводящие к тормозам. Похоже, единственная реальная польза от Cython заключается в возможности запускать Python-скрипты там, где не установлен интерпретатор. И не требуется высокая производительность. Зато читатели знают.
3. Замеряем объем потребляемой памяти
Давайте немного изменим задачу. Теперь нужно не просто извлечь из файла все имена пользователей, но и избавиться от дублей. То есть, программа должна выводить список уникальных ник-неймов. С помощью утилиты sort легко проверить, что в файле содержится всего около 3000 уникальных ников, так что можно смело хранить их в памяти. В предыдущем пункте мы выяснили, что предварительная компиляция регулярных выражений в Python только вредит, так что на этот раз обойдемся без *comp_re* скриптов. Тем более, что они не должны существенно влиять на потребление памяти.
Следует обратить внимание, что «память, используемая процессом» — штука очень относительная. Например, некоторые страницы могут попасть в своп. Кроме того — часть памяти отводится под саму программу (секция text), часть — под стек, часть — под данные (секция data). Что, если программа весит 20 Мб, но под данные выделяет только 100 Кб памяти? А если программа и данные вместе занимают 10 Кб, а под стек выделен 1 Мб? Также в Python очень активно используется разделяемая память — она считается или нет? (Кстати, к вопросу о том, зачем мне этот ваш ассемблер, если я пишу на Python.)
Я решил сделать две версии скриптов. Первая версия — нормальная, хранящая имена пользователей в памяти и выводящая только уникальные ники. Вторая версия выводит все логины (с повторами) в stdout, как в предыдущем пункте. Для обоих вариантов замеряем максимальную resident memory size и находим разность результатов. Эта разность принимается равной объему памяти, необходимому для хранения логинов.
#!/usr/bin/env python
import sys
import re
# Возможно, используя set вместо dict, будут получены другие результаты
# Можете считать проверку этого своим домашним заданием
nicks = dict ( )
for currNick in nicks. keys ( ) :
print currNick
#!/usr/bin/env perl
use strict ;
print «$_ \n » for ( keys %nicks ) ;
Программа на C++, обещанная еще в предыдущем пункте:
/* (c) Alexandr A Alexeev 2011 | http://eax.me/ */
#include
#include
#include
#include //
#include
using namespace std ;
namespace std <
namespace tr1 = :: boost ;
>
int main ( int argc, char ** argv ) <
set string > nicks ;
string line ;
tr1 :: smatch match ;
tr1 :: regex re ( «foobarbaz[^>]*>([a-zA-Z0-9_]+)
» ) ;
while ( infile. good ( ) ) <
getline ( infile, line ) ;
if ( tr1 :: regex_search ( line, match, re ) ) <
nicks. insert ( match [ 1 ] ) ;
>
>
Здесь мне следовало бы использовать unordered_set, оператор auto и встроенные регулярные выражения C++0x. К сожалению, поддержки всего этого нет в GCC 4.2, а скачать компилятор посвежее я поленился.
Собирается программа следующей командой:
Вы могли заметить, что теперь в Python-скрипте мы читаем данные из файла, а не из stdin, как делали это в пункте 2. Это не случайно. Во-первых, сейчас нас не интересует скорость скрипта. Во-вторых, мы не можем измерять параметры утилиты cat, как делали это в прошлый раз. Очевидно, что объем потребляемой ею памяти никак не связан с объемом памяти, используемой скриптами. То есть, утилита time теперь используется так:
Были получены следующие результаты:
Программы с постфиксом «_u» (от «unique») хранят логины в памяти и выводят только уникальные имена.
Perl снова превзошел Python, выделив под хранение данных около 70 Кб памяти. Пайтону в свою очередь понадобилось 80-95 Кб. А вот память, использованную программой на C++, похоже, просто не удалось замерить! Очевидно, что 3000 ников, имеющих среднюю длину 8 символов, никак не умещаются в 4 Кб памяти. Даже если в GNU-версии STL контейнер set использует для хранения строк какое-то хитрое дерево символов. Применение алгоритма сжатия также маловероятно. Скорее всего, программа в обоих случаях зарезервировала немного памяти на будущее, чтобы сократить число системных вызовов.
Интересно, что в данном случае программы на C++ потребляли больше памяти, чем скрипты на Perl или Python. Но не спешите радоваться — для более крупных программ такого происходить не будет. Кроме того, можно поиграться с флагами компилятора, чтобы сократить объем используемой памяти.
4. Выводы
Каждый способен сделать собственные выводы из этой заметки. Для себя я сделал следующие:
Соглашаться с этими выводами или нет — дело ваше.
5. Дополнительная инфа
Другие материалы, посвященные производительности Пайтона:
Дополнение: Относительно двух последних статей. К моему великому сожалению, в обоих случаях сравнивается скорость Python скрипта после оптимизации со скоростью того же скрипта до оптимизации. Допустим, скрипт стал в 500 раз быстрее. Спрашивается — насколько это быстрее/медленнее по сравнению с реализацией на C++ или Perl? Также ничего не говорится по поводу используемых объемов памяти.
Дополнение: А еще недавно я застукал BitTorrent-клиент Deluge (написанный угадайте-на-чем) за поеданием порядка 900 Мб оперативной памяти:
Проблема проявляется только после длительной работы Deluge. В связи с этим я подозреваю, что винить в прожорливости программы следует garbage collector, который, по всей видимости, не справился со своей работой.
Как обычно, любые комментарии приветствуются. Только, пожалуйста, воздержитесь от воплей типа «В реальных задачах Питон в 20 раз быстрее этого вашего Пёрла, просто вы мерить не умеете» или высокоумных фраз в стиле «На практике 90% времени программы работают с диском и сетью, а не обрабатывают данные, да и память нынче дешевая». Можете доказать первое — пишите статью. Последнее является слабым утешением для тех, кто занимается именно вычислениями.
🐍 Помнить всё. Как работает память в Python
Python многое делает за нас. Мы привыкли не заботиться об управлении памятью и о написании соответствующего кода. Пусть эти процессы и скрыты, но без их понимания трудно подготовить производительный код для высоконагруженных задач. В этой статье мы рассмотрим модель памяти Python и то, как интерпретатор Python взаимодействует с оперативной памятью компьютера.
Диспетчер памяти: «командовать парадом буду я»
Диспетчер памяти — своеобразный портье, который регистрирует и расселяет гостей отеля. Каждый постоялец получает ключ с номером комнаты, так что ни один из гостей не может заселиться не в свой номер. Две программы не могут одновременно записать переменную в одно место виртуальной памяти.
Фактически за это отвечает даже не диспетчер задач, который ожидает гостей за регистрационной стойкой, а GIL — глобальная блокировка интерпретатора. GIL гарантирует: в один и тот же момент времени байт-код выполняется только одним потоком. Главное преимущество — безопасная работа с памятью, а основной недостаток в том, что многопоточное выполнение программ Python требует специфических решений.
Очевидно, программа не сама выполняет сохранение и освобождение памяти — ведь мы не пишем соответствующих инструкций. Интерпретатор лишь запрашивает диспетчер памяти сделать это. А диспетчер уже делегирует работу, связанную с хранением данных, аллокаторам — распределителям памяти.
Организация доступной виртуальной памяти
Непосредственно с оперативной памятью взаимодействует распределитель сырой памяти (raw memory allocator). Поверх него работают аллокаторы, реализующие стратегии управления памятью, специфичные для отдельных типов объектов. Объекты разных типов — например, числа и строки — занимают разный объем, к ним применяются разные механизмы хранения и освобождения памяти. Аллокаторы стараются не занимать лишнюю память до тех пор, пока она не станет совершенно необходимой — этот момент определен стратегией распределения памяти CPython.
Python использует динамическую стратегию, то есть распределение памяти выполняется во время выполнения программы. Виртуальная память Python представляет иерархическую структуру, оптимизированную под объекты Python размером менее 256 Кб:
Блок содержит не более одного объекта Python и находится в одном из трех состояний:
Арена
Информацию о текущем распределении памяти в аренах, пулах и блоках можно посмотреть, запустив функцию sys._debugmallocstats() :
Чтобы не произошло утечки памяти, диспетчер памяти должен отследить, что вся выделенная память освободится после завершения работы программы. То есть при завершении программы CPython дает задание очистить все арены.
Освобождение памяти: счетчик ссылок, сборщик мусора
Для освобождения памяти используются два механизма: счетчик ссылок и сборщик мусора.
Однако счетчик ссылок неспособен отследить ситуации с циклическими ссылками. К примеру, возможна ситуация, когда два объекта ссылаются друг на друга, но оба уже не используются программой. Для борьбы с такими зависимостями используется сборщик мусора ( garbage collector ).
Заключение
Сохранение и освобождение блоков памяти требует времени и вычислительных ресурсов. Чем меньше блоков задействовано, тем выше скорость работы программы. Позволим себе дать несколько советов, касающихся экономной работы с памятью:
На Python создают прикладные приложения, пишут тесты и бэкенд веб-приложений, автоматизируют задачи в системном администрировании, его используют в нейронных сетях и анализе больших данных. Язык можно изучить самостоятельно, но на это придется потратить немало времени. Если вы хотите быстро понять основы программирования на Python, обратите внимание на онлайн-курс «Библиотеки программиста». За 30 уроков (15 теоретических и 15 практических занятий) под руководством практикующих экспертов вы не только изучите основы синтаксиса, но и освоите две интегрированные среды разработки (PyCharm и Jupyter Notebook), работу со словарями, парсинг веб-страниц, создание ботов для Telegram и Instagram, тестирование кода и даже анализ данных. Чтобы процесс обучения стал более интересным и комфортным, студенты получат от нас обратную связь. Кураторы и преподаватели курса ответят на все вопросы по теме лекций и практических занятий.