Skip to content

Latest commit

 

History

History
182 lines (146 loc) · 6.64 KB

highlights.rst

File metadata and controls

182 lines (146 loc) · 6.64 KB

Highlights

As mentioned in :doc:`README <index>`, this library is a collection of various utilities for working in Django. This document highlights some of the most useful features. To see all of them you can either browse the source code or browse the API docs.

Models

Base models are available with common attributes:

Model fields

Useful fields:

Form fields

Signals

Model signal utility decorators:

Middleware

Decorators

Utilities

  • :py:class:`cache <django_auxilium.utils.functools.cache.cache>` - decorator for caching either stand-alone functions or class methods so that they are only executed once. Useful for expensive functions which do not accept any parameters:

    >>> @cache
    def my_expensive_function():
    ...     return list(zip(range(1000000), range(1000000)))
    
  • :py:class:`memoize <django_auxilium.utils.functools.cache.memoize>` - decorator for caching either stand-alone functions or class methods which cache results per given parameters so that subsequent calls with same parameters are not executed. Useful for expensive functions which accept parameters:

    >>> @memoize
    ... def fib(n):
    ...     if n == 0:
    ...         return 0
    ...     elif n == 1:
    ...         return 1
    ...     else:
    ...         return fib(n - 1) + fib(n - 2)
    
  • :py:class:`lazy <django_auxilium.utils.functools.lazy.lazy>` - decorator for making functions execute lazily. They only execute once any operation is executed on their result, including type checking:

    >>> @lazy(str)
    ... def foo(self):
    ...     print('executing foo')
    ...     return foo
    
    >>> f = foo()
    >>> isinstance(f, str)
    executing foo
    True
    >>> f == 'foo'
    True
    

Bases

These base decorator classes are available which can be used to create class-based-decorators. They aim to provide to decorators what Django did with class-based-views to regular views. Both have a place however for more complex tasks separating logic within decorator might be more useful. As a matter of fact, the above decorators are all implemented on top of these base classes:

  • :py:class:`Decorator <django_auxilium.utils.functools.decorators.Decorator>` - this is a base class for creating class-based-decorators:

    >>> class MyPartialDecorator(Decorator):
    ...     def __init__(self, *args, **kwargs):
    ...         self.args = args
    ...         self.kwargs = kwargs
    ...     def get_wrapped_object(self):
    ...         def wrapper(*args, **kwargs):
    ...             _args = self.args + args
    ...             _kwargs = self.kwargs.copy()
    ...             _kwargs.update(kwargs)
    ...             return self.to_wrap(*_args, **_kwargs)
    ...         return wrapper
    
    >>> my_partial = MyPartialDecorator.as_decorator()
    
  • :py:class:`HybridDecorator <django_auxilium.utils.functools.decorators.HybridDecorator>` - this is a base class for creating class-based-decorators which can wrap both standalone functions and class methods:

    >>> class MyDecorator(Decorator):
    ...     def get_wrapped_object(self):
    ...         if self.in_class:
    ...             # class method
    ...         else:
    ...             # standalone function
    
    >>> my_decorator = MyDecorator.as_decorator()