|
2 | 2 | Introduction
|
3 | 3 | ############
|
4 | 4 |
|
5 |
| -Installation |
| 5 | +The firebird-base package is a set of Python 3 modules commonly used by Firebird Project in |
| 6 | +various development projects (for example the firebird-driver). However, these modules have |
| 7 | +general applicability outside the scope of development for Firebird RDBMS. |
| 8 | + |
| 9 | +Common data types |
| 10 | +================= |
| 11 | + |
| 12 | +The `.types` module provides collection of classes and other types that are often used by |
| 13 | +other library modules or applications. |
| 14 | + |
| 15 | +* Exception `.Error` that is intended to be used as a base class of all application-related |
| 16 | + errors. The important difference from `Exception` class is that `.Error` accepts keyword |
| 17 | + arguments, that are stored into instance attributes with the same name. |
| 18 | +* `.Singleton` base class for singletons. |
| 19 | +* `.Sentinel` base class for named sentinel objects that provide meaningful `str` and `repr`, |
| 20 | + along with collection of predefined sentinels. |
| 21 | +* `.Distinct` abstract base class for classes (incl. dataclasses) with distinct instances. |
| 22 | +* Collection of `Enums` and `custom string types`. |
| 23 | + |
| 24 | +Various collection types |
| 25 | +======================== |
| 26 | + |
| 27 | +The `.collections` mod
8000
ule provides data structures that behave much like builtin `list` and |
| 28 | +`dict` types, but with direct support of operations that can use structured data stored in |
| 29 | +container, and which would normally require utilization of `operator`, `functools` or other |
| 30 | +means. |
| 31 | + |
| 32 | +All containers provide next operations: |
| 33 | + |
| 34 | +* `filter` and `filterfalse` that return generator that yields items for which expr is |
| 35 | + evaluated as True (or False). |
| 36 | +* `find` that returns first item for which expr is evaluated as True, or default. |
| 37 | +* `contains` that returns True if there is any item for which expr is evaluated as True. |
| 38 | +* `occurrence` that returns number of items for which expr is evaluated as True. |
| 39 | +* `all` and `any` that return True if expr is evaluated as True for all or any list element(s). |
| 40 | +* `report` that returns generator that yields data produced by expression(s) evaluated on list items. |
| 41 | + |
| 42 | +Individual collection types provide additional operations like splitting and extracting |
| 43 | +based on expression etc. |
| 44 | + |
| 45 | +Expressions used by these methods could be strings that contain Python expression referencing |
| 46 | +the collection item(s), or lambda functions. |
| 47 | + |
| 48 | +Data conversion from/to string |
| 49 | +============================== |
| 50 | + |
| 51 | +While Python types typically support conversion to string via builtin `str()` function (and |
| 52 | +custom `__str__` methods), there is no symetric operation that converts string created by |
| 53 | +`str()` back to typed value. Module `.strconv` provides support for such symetric conversion |
| 54 | +from/to string for any data type. |
| 55 | + |
| 56 | +Symetric string conversion is used by `.config` module, notably by `.ListOption` and |
| 57 | +`.DataclassOption`. You can extend the range of data types supported by these options by |
| 58 | +registering convertors for required data types. |
| 59 | + |
| 60 | +Configuration definitions |
| 61 | +========================= |
| 62 | + |
| 63 | +Complex applications (and some library modules like `logging`) could be often parametrized |
| 64 | +via configuration. Module `.config` provides a framework for unified structured configuration |
| 65 | +that supports: |
| 66 | + |
| 67 | +* configuration options of various data type, including lists and other complex types |
| 68 | +* validation |
| 69 | +* direct manipulation of configuration values |
| 70 | +* reading from (and writing into) configuration in `configparser` format |
| 71 | +* exchanging configuration (for example between processes) using Google protobuf messages |
| 72 | + |
| 73 | +Memory buffer manager |
| 74 | +===================== |
| 75 | + |
| 76 | +Module `.buffer` provides a raw memory buffer manager with convenient methods to read/write |
| 77 | +data of various data type. |
| 78 | + |
| 79 | +Hook manager |
6 | 80 | ============
|
7 | 81 |
|
8 |
| -:: |
| 82 | +Module `.hooks` provides a general framework for callbacks and “hookable” events, that |
| 83 | +supports multiple usage strategies. |
| 84 | + |
| 85 | +Context-based logging |
| 86 | +===================== |
| 87 | + |
| 88 | +Module '.logging' provides context-based logging system built on top of standard `logging` |
| 89 | +module. |
| 90 | + |
| 91 | +The context-based logging: |
| 92 | + |
| 93 | +* Adds context information (defined as combination of topic, agent and context string values) |
| 94 | + into `~logging.LogRecord`, that could be used in logging message. |
| 95 | +* Adds support for f-string message format. |
| 96 | +* Allows assignment of loggers to specific contexts. The `.LoggingManager` class maintains |
| 97 | + a set of bindings between `Logger` objects and combination of `agent`, `context` and `topic` |
| 98 | + specifications. It’s possible to bind loggers to exact combination of values, or whole |
| 99 | + sets of values using `.ANY` sentinel. It means that is possible to assign specific Logger |
| 100 | + to log messages for particular agent in any context, or any agent operating in specific |
| 101 | + context etc. |
| 102 | + |
| 103 | +Trace/audit for class instances |
| 104 | +=============================== |
| 105 | + |
| 106 | +Module `.trace` provides trace/audit logging for functions or object methods through |
| 107 | +context-based logging provided by `.logging` module. |
| 108 | + |
| 109 | +The trace logging is performed by `.traced` decorator. You can use this decorator directly, |
| 110 | +or use `.TracedMixin` class to automatically decorate methods of class instances on creation. |
| 111 | +Each decorated callable could log messages before execution, after successful execution or |
| 112 | +on failed execution (when unhandled execption is raised by callable). The trace decorator |
| 113 | +can automatically add `agent` and `context` information, and include parameters passed to |
| 114 | +callable, execution time, return value, information about raised exception etc. to log messages. |
| 115 | + |
| 116 | +The trace logging is managed by `.TraceManager`, that allows dynamic configuration of traced |
| 117 | +callables at runtime. |
9 | 118 |
|
10 |
| - pip install firebird-base |
| 119 | +Registry for Google Protocol Buffer messages and enums |
| 120 | +====================================================== |
11 | 121 |
|
12 |
| -.. note:: Requires Python 3.8+ |
| 122 | +Module `.protobuf` provides central registry for Google Protocol Buffer messages and enums. |
| 123 | +The generated *_pb2.py protobuf files could be registered using `.register_decriptor` or |
| 124 | +`.load_registered` function. The registry could be then used to obtain information about |
| 125 | +protobuf messages or enum types, or to create message instances or enum values. |
0 commit comments