Skip to main content

Classic Operations

Библиотека предоставляет примитив для выделения границ операций в приложении.

Введение

Общая проблема, которую эта библиотека решает, это выделение границ операций у приложения и вызов на границах стороннего кода, не имеющего отношения к приложению.

Самый частый пример - использование транзакций в приложении. С одной стороны, хочется иметь декоратор вроде transactional, которым можно было бы просто обернуть метод в приложении, с другой стороны, хотелось бы, чтобы приложение не упоминало транзакции, так как это все-так больше имеет отношение к БД.

Объект-операция представляет собой контейнер, в которой можно положить контекстные менеджеры, и/или коллбеки. Затем объект операцию можно стартовать, при старте отработают контекстные менеджеры и коллбеки, затем, при завершении, соответствующие коллбеки и закроются контекстные менеджеры.

Пример:

from classic.operations import Operation, operation
from sqlalchemy import create_engine
from sqlalchemy.orm import Session


# Код приложения
class SomeService:
    
    # Dependency Injection
    def __init__(self, operation_: Operation):
        self.operation_ = operation_

    def some_method(self):
        with self.operation_:
            print('Здесь должна происходить полезная работа')
    
    @operation
    def another_method(self):
        """Этот метод полностью аналогичен some_method.
        Декоратор operation внутри обращается к self.operation_,
        и так же помещает в блок with. Сделано ради сахара.
        """
        print('Здесь должна происходить полезная работа')

# Композит
engine = create_engine('sqlite://')
session = Session(engine)
operation_ = Operation(context_managers=[session])
service = SomeService(operation_=operation_)

# Где-то в клиентском коде, например, в адаптерах:
service.some_method()

В примере каждый вызов some_method будет запуском операции. При входе в блок with будет вызван __enter__ у сессии, при выходе - __exit__, и, таким образом, произойдет обертывание метода в транзакцию, хотя код сервиса напрямую ничего о транзакции не упоминает.

Callbacks

Также можно повешать коллбеки на разные точки в жизненном цикле. Коллбеки не должны принимать никаких аргументов.

В примере указаны все возможные коллбеки:

from functools import partial
from classic.operations import Operation


lazy_print = partial(print)

operation_ = Operation(
    before_start=[lazy_print('Попытка начать операцию')],
    after_start=[lazy_print('Операция начата')],
    before_complete=[lazy_print('Операция успешно подходит к завершению')],
    after_complete=[lazy_print('Операция успешно завершена')],
    on_cancel=[lazy_print('Операция отменена')],
    on_finish=[lazy_print('Это вызовется после завершения '
                          'операции в любом случае')],
)

Порядок вызова при входе в блок with (__enter__):

  • before_start. Если хотя бы один из них вызовет исключение, исполнение прервется, будут вызваны on_cancel и on_finish, исключение будет выброшено наружу.

  • __enter__ у всех контекстных менеджеров, переданных в операцию. Если хотя бы из них вызовет исключение, исполнение прервется, будут вызваны on_cancel и on_finish, исключение будет выброшено наружу.

  • after_start. Если хотя бы один из них вызовет исключение, исполнение прервется, будут вызваны on_cancel и on_finish, исключение будет выброшено наружу.

Порядок вызова при выходе из блока with (__exit__):

  • before_complete. Если хотя бы один из них вызовет исключение, исполнение не прервется сразу, так как необходимо попытаться вызвать __exit__ у всех контекстных менеджеров из операции. Исключение будет отложено, но на следующем шаге оно будет передано в __exit__ каждому контекстному менеджеру.

  • __exit__ у всех контекстных менеджеров, переданных в операцию. Если хотя бы один из них вызовет исключение, исполнение не должно прерваться, сразу, все методы __exit__ у всех вложенных контекстных менеджеров должны быть вызваны.

    Если при этом произошло исключение, или есть исключение, отложенное с предыдущего шага, то исполнение прервется, будут вызваны on_cancel и on_finish, исключение будет выброшено наружу.

  • after_complete. Если хотя бы из них вызовет исключение, исполнение прервется, будут вызваны on_cancel и on_finish, исключение будет выброшено наружу

Динамические callbacks

Объект-операция предоставляет способ добавить коллбеки уже после запуска самой операции, внутри блока with. Такие коллбеки будут одноразовыми, объект-операция забудет о них после завершения текущей операции.

Вне запущенный операции эти методы вызывать нельзя, они будут генерировать исключение AssertionError

Пример:

from classic.operations import Operation, operation

class SomeService:
    
    # Dependency Injection
    def __init__(self, operation_: Operation):
        self.operation_ = operation_

    @operation
    def some_method(self):
        self.operation_.after_complete(
            lambda: print('Операция завершена успешно')
        )
        print('Здесь должна происходить полезная работа')
    
    @operation
    def another_method(self):
        print('Еще один очень полезный метод')

service = SomeService(operation_=Operation())

# Выведет сначала "Здесь должна происходить полезная работа",
# затем "Операция завершена успешно"
service.some_method()

# Выведет только "Еще один очень полезный метод"
service.another_method()

Счетчик вызовов

В операцию встроен счетчик вызовов. Повторный вход в блок with с операцией после входа не вызовет прогон коллбеков заново:

from classic.operations import Operation, operation

class SomeService:
    
    # Dependency Injection
    def __init__(self, operation_: Operation):
        self.operation_ = operation_

    @operation
    def some_method(self):
        self.another_method()
    
    @operation
    def another_method(self):
        print('Еще один очень полезный метод')

service = SomeService(operation_=Operation())

# Второй вызов operation в этой операции будет пропущен.
service.some_method()

Потокобезопасность

Объект-операция построен на базе threading.local, его можно использовать из разных потоков.

Декоратор operation

Декоратор operation сделан ради "сахара". Его применение позволяет не писать весь код метода на один tab справа, и, вероятно, покроет 95% случаев использования библиотеки.

Кроме того, декоратор использует extra_annotations из classic.components, из-за этого, при применении декоратора operation с components, можно не прописывать Operation в зависимостях:

from classic.components import component
from classic.operations import operation


@component
class SomeService:

    @operation
    def some_method(self):
        print('95% кейс)))')

Также можно указать, какое поле у self будет использовать декоратор:

from classic.operations import operation


class SomeService:
    
    def __init__(self, read, write, source_repo, target_repo):
        self.read = read
        self.write = write
        self.source_repo = source_repo
        self.target_repo = target_repo

    @operation('read')
    def some_method(self):
        # Представьте себе, что здесь происходит обращение к одной БД,
        # проверка и преобразование данных, и запись одной транзакцией в другую
        some_objects = self.source_repo.load_objects()
        with self.write:
            self.target_repo.write(some_objects)

Отмена операции

Для отмены операции используется исключение Cancel:

from classic.components import component
from classic.operations import operation, Cancel, Operation

@component
class SomeService:
    
    @operation
    def plain_usage(self):
        # после этого исключения class Operation произведет отмену операции, 
        # при этом исключение Cancel будет выброшено наружу 
        raise Cancel
    
    @operation
    def plain_usage_with_suppress(self):
        # Если установить suppress=True, так же произойдет отмена, 
        # но исключение НЕ БУДЕТ выброшено наружу  
        raise Cancel(suppress=True)
    
    @operation
    def class_usage(self):
        # добавлено ради сахара, ведет себя точно так же 
        raise Operation.Cancel

    @operation
    def decorator_usage(self):
        # добавлено ради сахара, ведет себя точно так же
        raise operation.Cancel
    

Строго говоря, для отмены операции можно использовать любое исключение. Cancel добавлен для возможности подавить распространение исключения.

Metadata

Release files for classic-operations 0.3.4

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for classic-operations 0.3.4
File Size Uploaded Provenance
classic_operations-0.3.4.tar.gz 12.9 kB With provenance Details

Built distribution (wheel)

Table of built distributions (wheels) for classic-operations 0.3.4
File Interpreter ABI Platform
classic_operations-0.3.4-py3-none-any.whl Python 3 none any Details

Total release size: 22.2 kB

Release files / classic_operations-0.3.4.tar.gz

Download URL classic_operations-0.3.4.tar.gz
Size 12.9 kB
Tags Source
SHA-256 checksum
How to use checksums
c5f009e970aa7cc2948695ba61ca11d52ebacfc786522002c84f7bfe4d2d414a
BLAKE2b-256 checksum
How to use checksums
e2178b40ce84adfc56f55f100b7d61800bf8930d08c2859eb9e955987d08c8ce
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/6.1.0 CPython/3.13.7

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 11, 2025.

Transparency log

Release files / classic_operations-0.3.4-py3-none-any.whl

Download URL classic_operations-0.3.4-py3-none-any.whl
Size 9.3 kB
Tags Python 3
SHA-256 checksum
How to use checksums
7ac7f1c2ef67e2a75d9039a847cf759883102701440ff212c6d7af790dfbda46
BLAKE2b-256 checksum
How to use checksums
290bf998ed0f24f1d2dea6b6744fb4dc3ca1b3ea1b36a7b014b13ad0e9422a06
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/6.1.0 CPython/3.13.7

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 11, 2025.

Transparency log

Security for classic-operations 0.3.4

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

Full provenance

All 2 files in this release have been uploaded with provenance metadata.

Select from 2 files

Attestation for classic_operations-0.3.4.tar.gz

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 11, 2025.

Transparency log

A note on package security

PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.

To learn more about protecting yourself from malicious actors, visit our package security documentation.

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page