TGTGInsighttelegram intelligenceLIVE / telegram public index
← Python Заметки

TGINSIGHT SIMILAR POSTS

Најди сличен содржај

Изворен канал @pythonotes · Post #197 · 4 јан.

Подразумеваемые неймспейсы или неявные пакеты. Этот функционал добавлен в Python 3.3 Что он означает? Ранее, до 3.3 пакетами считались лишь директории, в которых есть файл __init__.py. Этот файл одновременно являлся свидетельством того, что директория это Python-пакет, и служил "телом" этого пакета. То есть местом, где можно написать код, как это делается внутри модуля. Этот код исполняется в момент импорта пакета, так что его принято называть "код инициализации пакета". Начиная с версии 3.3 Любая директория считается пакетом и Python будет пытаться использовать любую директорию для импорта. Конечно, не любую в файловой системе, а только те что находятся в sys.path. Это значит, что теперь __init__.py нужно делать только если: 🔸 вам требуется создать код инициализации пакета 🔸 нужна совместимость со старыми версиями Python На мой взгляд это немного упрощает разработку, делает её чище, но с другой стороны убивает некоторую однозначность происходящего. Например, я создал репозиторий со своей библиотекой и рядом положил код примеров или тестов. repo_name/ my_library/ __init__.py main.py examples/ exam1.py exam2.py В этом репозитории пакетом является только my_library, остальные директории это не пакеты, это просто дополнительный код в файлах. Директория examples не добавлена в sys.path, в ней нет рабочих модулей. Но если она лежит рядом с my_library, то Python вполне сможет импортнуть из неё модули, так как посчитает что examples это валидный пакет. Конечно, пример несколько надуманный. Никто не будет добавлять корень репозитория в sys.path. Но, я думаю, суть ясна. Иногда директория это просто директория а не пакет! #basic#pep

Hashtags

Резултати

Пронајдени 2 слични објави

Пребарај: #numa

当前筛选 #numa清除筛选
DOFH - DevOps from hell

@dofh_ru · Post #3851 · 03.09.2025 г., 12:20

Proxmox: привязка CPU к виртуальным машинам Не всегда очевидно, зачем вообще нужна привязка CPU к виртуальным машинам, особенно если речь идёт о небольших развертываниях - там этот параметр чаще всего просто игнорируют. Но в реальном продакшене использование CPU affinity становится действительно важным для повышения производительности виртуалок. https://telegra.ph/Proxmox-privyazka-CPU-k-virtualnym-mashinam-09-03 #ит_статьи#devops#proxmox#linux#numa

DOFH - DevOps from hell

@dofh_ru · Post #3937 · 24.11.2025 г., 06:45

Почему мое приложение на 2 vCPU работает быстрее в виртуалке, чем в контейнере? С ростом популярности Kubernetes и контейнеров многие команды не только разрабатывают и разворачивают новые приложения сразу под Kubernetes, но и переносят туда уже существующие сервисы. Эти сервисы до этого могли работать на bare metal серверах или на виртуальных машинах. Контейнеры реализуют идею «Собрал один раз — запускай где угодно», что позволяет командам разработки и эксплуатации управлять приложениями легче и более системно. Но довольно часто после переноса приложения как есть в Kubernetes производительность вдруг оказывается ниже ожидаемой. Эта заметка в первую очередь смотрит на проблему со стороны CPU: почему при переносе сервисов из VM в мир Kubernetes (контейнеров) могут возникнуть определённые сложности и как они могут привести к просадке в производительности. Внутренние узкие места самого приложения — сетевой ввод-вывод, дисковый ввод-вывод и тому подобное — остаются за рамками обсуждения. https://telegra.ph/Pochemu-moe-prilozhenie-na-2-vCPU-rabotaet-bystree-v-virtualke-chem-v-kontejnere-11-24 #ит_статьи#devops#kubernetes#performance#numa#cgroups#cpulimit