Программистика

👀 Causal Inference на Python. Причинно-следственные связи в IT-разработке Сколько покупателей привлечет дополнительный доллар, вложенный в онлайн-рекламу? Какие клиенты будут покупать только по скидочному купону? Как разработать оптимальную стратегию ценообразования? Причинно-следственный анализ (casual inference) — лучший способ разобраться, как влиять на бизнес-метрики, которыми вы хотите управлять. И для этого понадобится всего пара строк кода на Python. Матеуш Факур рассказывает про малоизвестные применения причинно-следственного анализа, с помощью которых можно оценить влияние воздействия на результат. Программистика|| #doc

Создание приложения на Python и Flask Flask — один из самых популярных веб-фреймворков для Python. Его используют как новички, так и профессиональные разработчики. В этой инструкции мы покажем, как с ним работать, создав простое приложение. ➡️ Читать статью Программистика || #article

🖥 ​Prefect - это оркестрации рабочих процессов с открытым исходным кодом, предназначенный для создания надежных конвейеров обработки данных на Python!

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

🐱 Ссылка на GitHub Программистика || #Library

НЕ ПОКУПАЙ КУРСЫ В ИНТЕРЕНЕТ И НЕ ИДИ В ВУЗ! ❌ Курсы — СКАМ чистой воды, ❌ В ВУЗ'е тебя учат 60 летние бабки программировать в 1С Самый лучший вариант — канал Влада Все знания в IT, которые он получил за 11+ лет коммерческого опыта он рассказывает в своём канале абсолютно бесплатно. Всего 10 минут в день в канале Влада и ты поймешь, как нужно правльно учиться и искать работу👇 https://t.me/+Nrnh4uEZr7szY2Yy

📦 Мемоизация: магия @lru_cache или свой велосипед? Нужно считать тяжёлые функции быстро? Запомни результат - не считай по 100 раз. 1️⃣ В чём суть Мемоизация - это кеширование возвращаемых значений функции для уже обработанных аргументов. 2️⃣ Стандартный путь: @lru_cache

from functools import lru_cache

@lru_cache(maxsize=128)
def fibonacci(n: int) -> int:
    if n < 2:
        return n
    return fibonacci(n - 1) + fibonacci(n - 2)

# Всё. Работает. Не надо думать.

3️⃣ Свой велосипед: замыкания

def manual_memoize(func):
    cache = {}  # Вот и весь секрет - словарь в замыкании

    def wrapper(*args):
        if args not in cache:
            cache[args] = func(*args)
        return cache[args]
    return wrapper

@manual_memoize
def heavy_calculation(x):
    # Какая-то долгая хрень
    return x * x

4️⃣ Зачем это надо?

🔴 @lru_cache - готово, проверено, есть TTL и статистика. 🔴 Свой кеш - полный контроль, микрооптимизации, нестандартные ключи. 🔴 Не надо тащить либы для одной фичи. 🔴 Понять, как работает магия внутри.

5️⃣ Нюансы

🔴 @lru_cache не работает с unhashable аргументами (списки, словари) без костылей. 🔴 Ручной кеш - твоя ответственность за очистку и утечки памяти. 🔴 Для 99% случаев встроенного декоратора хватает за глаза.

Программистика ||#article

📦 Мемоизация: магия @lru_cache или свой велосипед? Нужно считать тяжёлые функции быстро? Запомни результат - не считай по 100 раз. 1️⃣ В чём суть Мемоизация - это кеширование возвращаемых значений функции для уже обработанных аргументов. 2️⃣ Стандартный путь: @lru_cache

from functools import lru_cache

@lru_cache(maxsize=128)
def fibonacci(n: int) -> int:
    if n < 2:
        return n
    return fibonacci(n - 1) + fibonacci(n - 2)

# Всё. Работает. Не надо думать.

3️⃣ Свой велосипед: замыкания

def manual_memoize(func):
    cache = {}  # Вот и весь секрет - словарь в замыкании

    def wrapper(*args):
        if args not in cache:
            cache[args] = func(*args)
        return cache[args]
    return wrapper

@manual_memoize
def heavy_calculation(x):
    # Какая-то долгая хрень
    return x * x

4️⃣ Зачем это надо?

🔴 @lru_cache - готово, проверено, есть TTL и статистика. 🔴 Свой кеш - полный контроль, микрооптимизации, нестандартные ключи. 🔴 Не надо тащить либы для одной фичи. 🔴 Понять, как работает магия внутри.

5️⃣ Нюансы

🔴 @lru_cache не работает с unhashable аргументами (списки, словари) без костылей. 🔴 Ручной кеш - твоя ответственность за очистку и утечки памяти. 🔴 Для 99% случаев встроенного декоратора хватает за глаза.

Программистика ||#article

Лицо Udemy представили? — тут слили кучу курсов по IT от онлайн школ Материала почти на пол-терабайта, мы загрузили всё на канал, там есть: 🐍 Python и нейросети (28 полных курсов + библиотеки) 📈 Data Analysis + машинное обучение (15 курсов) 👨🏻‍💻 Frontend (от JS до React) — (20 курсов + библиотеки) 🤖 Backend + базы Данных (30 курсов) 🛡 Информационная безопасность (Защита+Атака) — (14 курсов) 🎮 Разработка игр (11 курсов) Всё можно забрать бесплатно и смотреть без скачивания ➡️ @IT_SLIV

👩‍💻 Модули vs Классы: Когда функции достаточно, а когда без ООП не обойтись В Python есть два подхода к организации кода: процедурный (модули с функциями) и объектно-ориентированный (классы). Новички часто создают классы там, где хватит функций ("это же круче!"), а сеньоры ругают избыточные иерархии. Разбираемся, где что использовать. 🧱 Когда `модули с функциями` — это достаточно и правильно: Простой модуль с функциями идеален, когда у вас нет состояния или оно минимально, а логика представляет собой набор операций. 1️⃣. Утилитарные функции (pure functions):

# math_utils.py — идеальный модуль
def clamp(value, min_val, max_val):
    return max(min_val, min(value, max_val))

def lerp(start, end, factor):
    return start + (end - start) * factor

# Никакого состояния, только преобразования

2️⃣. Конфигурация и константы:

# config.py — лучше модуля, чем класса-синглтона
DATABASE_URL = "postgresql://localhost/db"
API_TIMEOUT = 30
LOG_LEVEL = "INFO"

3️⃣. Скрипты и одноразовые задачи:

# data_cleaner.py — запустили, отработали, завершили
import pandas as pd

def load_data(path):
    return pd.read_csv(path)

def clean_data(df):
    return df.dropna()

if __name__ == "__main__":
    df = load_data("data.csv")
    cleaned = clean_data(df)
    # Всё, классы не нужны

🧱 Когда `классы` — это необходимость, а не прихоть: 1. Когда есть состояние (stateful объекты):

❌ Слабое решение на функциях:
balance = 1000

def withdraw(amount):
    global balance  # Опасно! Глобальное состояние
    balance -= amount
    return balance

✅ Чистый ООП-подход:
class BankAccount:
    def __init__(self, initial_balance):
        self._balance = initial_balance  # Инкапсуляция
    
    def withdraw(self, amount):
        if amount <= self._balance:
            self._balance -= amount
        return self._balance

2. Когда нужен полиморфизм:

class Notification:
    def send(self, message):
        raise NotImplementedError

class EmailNotification(Notification):
    def send(self, message):
        # Логика отправки email
        pass

class SMSNotification(Notification):
    def send(self, message):
        # Логика отправки SMS
        pass

# Одна функция работает с разными типами
def notify_users(users, notification: Notification):
    for user in users:
        notification.send(f"Hello, {user.name}!")

3. Когда объект имеет жизненный цикл:

class DatabaseConnection:
    def __init__(self, connection_string):
        self.conn = None
        self.connection_string = connection_string
    
    def __enter__(self):
        self.conn = connect(self.connection_string)
        return self
    
    def __exit__(self, *args):
        self.conn.close()
    
    def execute(self, query):
        return self.conn.execute(query)

# Контекстный менеджер управляет жизненным циклом

🧱 Антипаттерны (что делать НЕ НАДО): 1. Класс как namespace для функций:

❌ Бессмысленный класс:
class MathOperations:
    @staticmethod
    def add(a, b):
        return a + b
    
    @staticmethod
    def multiply(a, b):
        return a * b

# Используем: MathOperations.add(2, 3) — избыточно!

✅ Просто модуль:
# math_ops.py
def add(a, b):
    return a + b

def multiply(a, b):
    return a * b

2. Функции там, где нужно состояние:

❌ Функции с кучей параметров:
def process_user_data(user_id, db_conn, cache, logger, config):
    # 5 параметров — явный признак, что нужен класс
    pass

✅ Класс, инкапсулирующий зависимости:
class UserProcessor:
    def __init__(self, db_conn, cache, logger, config):
        self.db = db_conn
        self.cache = cache
        self.logger = logger
        self.config = config
    
    def process(self, user_id):
        # Все зависимости уже есть в self
        pass

💡 Практическое правило выбора: Выбирай модуль с функциями, если:

🟢 Операции не имеют состояния (pure functions) 🟢 Данные преобразуются, а не хранятся 🟢 Нужен набор утилит или констант 🟢 Код будет использоваться как библиотека

🔗 Подробнее в статье Программистика ||#article

👩‍💻 pydantic-settings: Конфигурация приложений без хаоса и костылей Если ты хранишь настройки в случайных местах: то в .env, то в yaml, то в переменных окружения, а потом городишь костыли из os.getenv() с дефолтами — пора навести порядок. ❌ Было (типичный хаос):

import os
from dotenv import load_dotenv

load_dotenv()  # А если файла нет?

DB_HOST = os.getenv("DB_HOST", "localhost")  # Дефолты раскиданы по коду
DB_PORT = int(os.getenv("DB_PORT", 5432))    # Приведение типов вручную
DEBUG = os.getenv("DEBUG", "False") == "True"  # Конвертация строки в bool

# А если нужно добавить новую настройку? Ищем все os.getenv() по проекту...

✅ Стало (pydantic-settings):

from pydantic_settings import BaseSettings
from pydantic import Field

class Settings(BaseSettings):
    db_host: str = "localhost"
    db_port: int = 5432
    debug: bool = False
    api_key: str = Field(..., env="API_KEY")  # Обязательная переменная
    
    class Config:
        env_file = ".env"
        env_file_encoding = "utf-8"

config = Settings()  # Всё! Настройки загружены и проверены
print(f"Подключаемся к {config.db_host}:{config.db_port}")

pydantic-settings — это расширение Pydantic для управления конфигурацией. Оно умеет загружать настройки из кучи источников (env-файлы, переменные окружения, секреты) и валидировать их как обычные Pydantic-модели. ➕ Почему это меняет всё: 🟢 Единый источник правды: Все настройки в одном классе, а не раскиданы по модулям 🟢 Автоматическая загрузка: Ищет переменные в .env, окружении, ini-файлах — в правильном порядке 🟢 Валидация и типы: Pydantic сам преобразует строки в нужные типы и проверяет значения 🟢 Секреты и чувствительные данные: Поддержка docker secrets, vault и других хранилищ ➖ Особенности: ➖ Ещё одна зависимость в проекте (но если уже есть Pydantic, то она минимальна) ➖ Для совсем простых скриптов может быть избыточным 🧪 Пример продвинутой конфигурации:

from pydantic_settings import BaseSettings, SettingsConfigDict

class Settings(BaseSettings):
    model_config = SettingsConfigDict(
        env_file=".env",
        env_file_encoding="utf-8",
        env_prefix="APP_",  # APP_DB_HOST, APP_DEBUG
        secrets_dir="/run/secrets",  # Для Docker Swarm/Kubernetes
    )
    
    db_url: str
    redis_url: str = "redis://localhost:6379"
    log_level: str = "INFO"
    
    # Вложенные конфиги
    sentry: dict = {}
    
# Настройки автоматически загрузятся из APP_DB_URL, APP_REDIS_URL и т.д.
config = Settings()

Установка:

pip install pydantic-settings
# Или если уже есть Pydantic v2:
pip install "pydantic-settings[dotenv]"

💡 Идеально для: - Микросервисов и контейнеризованных приложений - Проектов с разными окружениями (dev/stage/prod) - Команд, где каждый тянет настройки по-своему - Любого проекта, где устали от os.getenv() Конфигурация должна быть простой, типобезопасной и предсказуемой. С pydantic-settings она именно такая. 🐱 Ссылка на репозиторий Программистика || #Library

Программистика || #Мемы

📂 PyTorch: Custom Ops - когда графы не справляются Если стандартные операции торчат узким местом, можно их переписать. Не магией, а C++ и CUDA. 1️⃣ В чём суть Кастомные операции (Custom Ops) позволяют заменить узлы в вычислительном графе PyTorch на свои, оптимизированные реализации. 2️⃣ Практика

# 1. Пишем ядро на C++/CUDA (my_custom_op.cpp)
#include <torch/extension.h>

torch::Tensor my_fast_op(torch::Tensor input) {
    // Твоя хрень вместо медленного PyTorch-эквивалента
    auto output = input.clone();
    // ... CUDA kernel launch или векторная оптимизация ...
    return output;
}

PYBIND11_MODULE(TORCH_EXTENSION_NAME, m) {
    m.def("my_fast_op", &my_fast_op, "My fast custom op");
}

# 2. Компилируем и загружаем в Python
from torch.utils.cpp_extension import load
custom_ops = load(name="my_ops", sources=["my_custom_op.cpp"])

# 3. Используем в модели
output = custom_ops.my_fast_op(input_tensor)

3️⃣ Почему это важно

🔴 Экзотичные активации 🔴 Специфичные потери (loss functions) 🔴 Квантование/спарсификация на лету 🔴 Аппаратно-специфичные оптимизации 🔴 Градиентные трюки, которых нет в torch.autograd

4️⃣ Нюансы

🔴 Нужно писать градиент вручную (forward/backward) 🔴 Отладка - жесть (gdb, CUDA-GDB) 🔴 Совместимость версий PyTorch 🔴 Может сломать JIT-трассировку

Программистика || #Статья

🤔 Mutable 🆚 Immutable: Когда менять, а когда — создавать заново В Python мир делится на изменяемые (mutable) и неизменяемые (immutable) объекты. Новички часто путают их, создавая баги с побочными эффектами, а сеньоры спорят, что лучше для производительности. Разбираемся, где мутабельность — это сила, а где — источник хаоса. 🧱 Когда `mutable` — это хорошо (и удобно): Изменяемые объекты (списки, словари, множества) идеальны, когда нужно накапливать или модифицировать данные без создания копий. 1️⃣. Накопление данных в цикле:

# Эффективно и понятно
results = []
for item in data_stream:
    processed = process_item(item)
    results.append(processed)  # Меняем на месте

2️⃣. Кэширование/мемоизация:

cache = {}  # Изменяемый словарь

def get_expensive_result(key):
    if key not in cache:
        cache[key] = calculate_expensive_thing(key)
    return cache[key]

3️⃣. Работа с большими данными:

# Избегаем копирования больших структур
def normalize_data(data_list):
    for i in range(len(data_list)):
        data_list[i] = data_list[i].lower()  # Меняем на месте

🧱 Когда `mutable` — это ПЛОХО (опасно): 1. Неожиданные побочные эффекты:

❌ ОПАСНО:
def add_to_list(item, target=[]):
    target.append(item)
    return target

print(add_to_list(1))  # [1]
print(add_to_list(2))  # [1, 2] ??? Аргумент по умолчанию сохранился!

2. Проблемы в многопоточности:

# Разные потоки меняют один список → состояние гонки
shared_list = []

def worker():
    shared_list.append(threading.get_ident())  # Кто успел, тот и записал

3. Сложная отладка:

config = {"debug": True, "level": "info"}

def setup_logging(cfg):
    cfg["level"] = "debug"  # Неявно меняет глобальный config!
    
setup_logging(config)
print(config["level"])  # "debug" — а кто менял?

🧱 Когда `immutable` — это безопасность: Неизменяемые объекты (строки, кортежи, frozenset) защищают от случайных изменений и упрощают логику. 1️⃣. Ключи словаря:

# Только неизменяемые объекты могут быть ключами
valid_cache = {("user", 123): "data"}  # Кортеж — OK
invalid_cache = {["user", 123]: "data"}  # TypeError

2️⃣. Защита константных данных:

# Координаты, настройки, конфиги
DEFAULT_SETTINGS = ("localhost", 8080)  # Никто не сможет изменить
CONFIG = frozenset(["api_key", "timeout"])  # Гарантированно неизменяемо

3️⃣. Предсказуемость в функциональном стиле:

def process_data(data_tuple):
    # Можно быть уверенным — data_tuple не изменился
    return sum(data_tuple) / len(data_tuple)

💡 Практическое правило: 🟢 Используй mutable, когда:

- Часто меняешь данные - Работаешь с большими объектами - Нужна максимальная производительность

🟢 Выбирай immutable, когда:

- Данные константны или редко меняются - Нужна потокобезопасность - Объект используется как ключ - Хочется избежать побочных эффектов

🗣 Запомни: Мутабельность — не "хорошо" или "плохо", а инструмент. Как молоток: в нужных руках строит, в неумелых — разбивает. Выбор между list и tuple, dict и MappingProxyType — это выбор между гибкостью и безопасностью. 🔗 Подробнее в статье Умные разработчики знают, когда позволить объекту меняться, а когда заморозить его для вечности. Программистика || #Статья

Почему 90% фронтендеров никогда не выйдут на большие чеки? Потому что бездумно потребляют «обучающий» контент. И топчутся в говне месяцами, рвут жопу за нищие копейки и терпят даунов-начальников, лишь бы не вылететь на улицу. Хотя чтобы стать разработчиком, надо в первую очередь научиться думать как разработчик. Хорошая новость в том, что тебе ничего кардинально менять не нужно, чтобы войти в «золотую десятку» самых успешных. Не надо бросать курсы или увольняться. Достаточно заменить источник информации: 👉 Фронтенд 👉 Верстка 👉 Node.JS 10–15 минут в день смотри на реальные задачи, живой код, ошибки, подходы и паттерны, которыми топовые фронты пользуются прямо сейчас. Это самый простой и дешёвый способ стать уважаемым специалистом, так что подписывайся.

👩‍💻 От `requirements.txt` до `uv`: эволюция управления зависимостями в Python Держать в проекте requirements.txt с версиями ==, >=, ~= и надеяться, что у всех разработчиков будет одинаковое окружение — это как играть в русскую рулетку при каждом pip install. А если добавить pipenv, poetry, pdm и новый uv — голова идёт кругом. Пора разобраться, какой инструмент когда использовать, чтобы не тратить часы на "у меня работает". 🧱 Проблема: почему старый добрый `requirements.txt` уже недостаточно requirements.txt — это просто список пакетов, не более. Нет блокировки версий зависимостей (только верхнего уровня), нет разделения dev/prod зависимостей, нет воспроизводимости сборок.

# requirements.txt — классика проблем
Django>=4.2  # Какая версия установится? 4.2? 5.0?
pandas  # Без версии — катастрофа воспроизводимости
numpy==1.24.3  # А если другой пакет требует numpy>=1.25?

Результат: "На моей машине работало" — классическая фраза на код-ревью. 📌 Современные инструменты: кто есть кто 1. `pipenv` — первая попытка исправить ситуацию

pipenv install django  # Создаёт Pipfile и Pipfile.lock

🟢 Плюсы: Единый файл для всех зависимостей, lock-файл для воспроизводимости. ⚠️ Минусы: Медленный, уже считается устаревшим, проблемы с производительностью. 2. `poetry` — стандарт для библиотек и приложений

# pyproject.toml — всё в одном файле
[tool.poetry]
name = "myproject"

[tool.poetry.dependencies]
python = "^3.9"
django = "^4.2"
pandas = "1.5.3"

[tool.poetry.group.dev.dependencies]
pytest = "^7.0"
black = "^23.0"

🟢 Плюсы: Управление версиями, публикация пакетов, быстрое разрешение зависимостей. ⚠️ Минусы: Своя экосистема команд, иногда сложности с Docker-образами. 3. `pdm` — современная альтернатива с PEP 582

pdm add django  # Использует __pypackages__ вместо virtualenv

🟢 Плюсы: Очень быстрый, поддерживает PEP 582 (пакеты рядом с кодом). ⚠️ Минусы: Менее популярен, некоторые инструменты не поддерживают. 4. `uv` — новый игрок от создателей `ruff`

uv pip install django  # Невероятно быстро
uv venv  # Создание виртуального окружения за миллисекунды
uv pip compile pyproject.toml -o requirements.txt  # Генерация lock-файла

🟢 Плюсы: Невероятная скорость (написано на Rust), совместимость с существующими файлами. ⚠️ Минусы: Очень молодой проект, некоторые фичи ещё в разработке. 🧪 Практический пример: миграция с `requirements.txt` на современный стек Было (хаос):

# requirements.txt
django>=4.2
gunicorn
psycopg2-binary
celery[redis]
django-debug-toolbar
pytest
black

Стало (порядок с `pyproject.toml`):

# pyproject.toml
[project]
name = "myproject"
dependencies = [
    "django>=4.2,<5.0",
    "gunicorn",
    "psycopg2-binary",
    "celery[redis]>=5.3",
]

[project.optional-dependencies]
dev = [
    "django-debug-toolbar",
    "pytest>=7.0",
    "black>=23.0",
]

[build-system]
requires = ["setuptools>=61.0", "wheel"]
build-backend = "setuptools.build_meta"

И отдельный файл для точных версий:

# Генерируем lock-файл одной командой
uv pip compile pyproject.toml -o requirements.txt
uv pip compile pyproject.toml --extra dev -o requirements-dev.txt

📌Управление зависимостями не должно быть болью. Современные инструменты делают его быстрым, предсказуемым и безопасным. Главное — выбрать подходящий для вашей команды и проекта. Программистика ||#article

First Step in NLP 2.0 Первый из серии мини-курсов, посвященный введению в Natural Language Processing и основам работы со строками в Python. Обновлен в ноябре 2023 года. Курс проводится преподавателями онлайн-магистратуры "Машинное обучение и высоконагруженные системы" факультета компьютерных наук Высшей школы экономики ➡️ Читать статью Программистика || #article

🖥 glom - это библиотека Python, предназначенная для упрощения доступа и преобразования вложенных структур данных! Она предоставляет декларативный подход к извлечению и модификации данных, позволяя разработчикам эффективно работать с комплексными иерархиями объектов и коллекций. 🐱 Ссылка на GitHub Программистика || #Library

Программистика || #Мемы

🌐 Web‑технологии Вы пользуетесь интернетом. Но знаете ли вы, как создаются сайты и веб‑приложения? Если вы когда‑то слышали слова HTML, HTTP, сервер, API, но не уверены, что они значат — мы поможем разобраться! В этом мини‑курсе вы в деталях узнаете о том, как устроен веб. Вы поймёте, как браузер получает информацию с сервера, как формируется страница, и почему всё работает почти мгновенно. Курс покажет, как взаимодействуют разные части веб‑приложения и как код превращается в то, что вы видите на экране. Всё это подано просто и доступно, чтобы вы могли сразу попробовать создавать свои первые сайты. 📎 Ссылка Программистика || #Course

Ускорьте работу разработки Cursor — IDE с ИИ, которая помогает писать код по описанию, искать ошибки и приводить проект в порядок быстрее обычного. Что делает: • генерирует и дополняет код на естественном языке • объясняет непонятные участки • находит ошибки и предлагает фиксы • подсказывает оптимизации и практики • работает как полноценная IDE, только быстрее Для компаний — это реальный способ ускорить команду без найма дополнительных разработчиков: меньше рутины, больше времени на архитектуру и продуктовые задачи. Попробовать Cursor: https://clck.ru/3QeE4z Поставщик в России — «Системный софт» (оплата в рублях, закрывающие документы и поддержка при подключении). Перейти на сайт #реклама 16+ syssoft.ru О рекламодателе

Курс Python с Абсолютного нуля

🎥 Первоисточник

Программистика|| #video