|
2 | 2 | Firebird base modules for Python
|
3 | 3 | ================================
|
4 | 4 |
|
5 |
| -The `firebird-base` package provides common Python 3 modules used by `Firebird Project`_ |
6 |
| -in various development projects. However, these modules have general applicability outside |
7 |
| -the scope of development for `Firebird`_ ® RDBMS. |
8 |
| - |
9 |
| -Topic covered by `firebird-base` package: |
10 |
| - |
11 |
| -* General data types like `singletons`, `sentinels` and objects with identity. |
12 |
| -* Unified system for data conversion from/to string. |
13 |
| -* `DataList` and `Registry` collection types with advanced data-processing cappabilities. |
14 |
| -* Work with structured binary buffers. |
15 |
| -* Global registry of Google `protobuf` messages and enumerations. |
16 |
| -* Extended configuration system based on `ConfigParser`. |
17 |
| -* Context-based logging. |
18 |
| -* Trace/audit for class instances. |
19 |
| -* General "hook" mechanism. |
| 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 or Saturnin). However, these |
| 7 | +modules have general applicability outside the scope of development for Firebird_. |
20 | 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` module 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 collection element(s). |
| 40 | +* `report` that returns generator that yields data produced by expression(s) evaluated on collection 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 `~firebird.base.config` module, notably by |
| 57 | +`~firebird.base.config.ListOption` and `~firebird.base.config.DataclassOption`. You can |
| 58 | +extend the range of data types supported by these options by registering convertors for |
| 59 | +required data types. |
| 60 | + |
| 61 | +Configuration definitions |
| 62 | +========================= |
| 63 | + |
| 64 | +Complex applications (and some library modules like `logging`) could be often parametrized |
| 65 | +via configuration. Module `~firebird.base.config` provides a framework for unified structured |
| 66 | +configuration that supports: |
| 67 | + |
| 68 | +* configuration options of various data type, including lists and other complex types |
| 69 | +* validation |
| 70 | +* direct manipulation of configuration values |
| 71 | +* reading from (and writing into) configuration in `configparser` format |
| 72 | +* exchanging configuration (for example between processes) using Google protobuf messages |
| 73 | + |
| 74 | +Additionally, the `ApplicationDirectoryScheme` abstract base class defines set of mostly |
| 75 | +used application directories. The function `get_directory_scheme()` could be then used |
| 76 | +to obtain instance that implements platform-specific standards for file-system location |
| 77 | +for these directories. Currently, only "Windows", "Linux" and "MacOS" directory schemes |
| 78 | +are supported. |
| 79 | + |
| 80 | +Memory buffer manager |
| 81 | +===================== |
| 82 | + |
| 83 | +Module `buffer` provides a raw memory buffer manager with convenient methods to read/write |
| 84 | +data of various data types. |
| 85 | + |
| 86 | +Hook manager |
| 87 | +============ |
| 88 | + |
| 89 | +Module `hooks` provides a general framework for callbacks and “hookable” events, that |
| 90 | +supports multiple usage strategies. |
| 91 | + |
| 92 | +Context-based logging |
| 93 | +===================== |
| 94 | + |
| 95 | +Module `logging` provides context-based logging system built on top of standard `logging` |
| 96 | +module. |
| 97 | + |
| 98 | +The context-based logging: |
| 99 | + |
| 100 | +* Adds context information (defined as combination of topic, agent and context string values) |
| 101 | + into `~logging.LogRecord`, that could be used in logging message. |
| 102 | +* Adds support for f-string message format. |
| 103 | +* Allows assignment of loggers to specific contexts. The `LoggingManager` class maintains |
| 104 | + a set of bindings between `Logger` objects and combination of `agent`, `context` and `topic` |
| 105 | + specifications. It’s possible to bind loggers to exact combination of values, or whole |
| 106 | + sets of values using `ANY` sentinel. It means that is possible to assign specific Logger |
| 107 | + to log messages for particular agent in any context, or any agent operating in specific |
| 108 | + context etc. |
| 109 | + |
| 110 | +Trace/audit for class instances |
| 111 | +=============================== |
| 112 | + |
| 113 | +Module `trace` provides trace/audit logging for functions or object methods through |
| 114 | +context-based logging provided by `logging` module. |
| 115 | + |
| 116 | +The trace logging is performed by `traced` decorator. You can use this decorator directly, |
| 117 | +or use `TracedMixin` class to automatically decorate methods of class instances on creation. |
| 118 | +Each decorated callable could log messages before execution, after successful execution or |
| 119 | +on failed execution (when unhandled exception is raised by callable). The trace decorator |
| 120 | +can automatically add `agent` and `context` information, and include parameters passed to |
| 121 | +callable, execution time, return value, information about raised exception etc. to log messages. |
| 122 | + |
| 123 | +The trace logging is managed by `TraceManager`, that allows dynamic configuration of traced |
| 124 | +callables at runtime. |
| 125 | + |
| 126 | +Trace supports configuration based on `~firebird.base.config`. |
| 127 | + |
| 128 | +Registry for Google Protocol Buffer messages and enums |
| 129 | +====================================================== |
| 130 | + |
| 131 | +Module `protobuf` provides central registry for Google Protocol Buffer messages and enums. |
| 132 | +The generated `*_pb2.py protobuf` files could be registered using `register_decriptor` or |
| 133 | +`load_registered` function. The registry could be then used to obtain information about |
| 134 | +protobuf messages or enum types, or to create message instances or enum values. |
| 135 | + |
| 136 | +Callback systems |
| 137 | +================ |
| 138 | + |
| 139 | +Module `~firebird.base.signal` provides two callback mechanisms: one based on signals and |
| 140 | +slots similar to Qt signal/slot, and second based on optional method delegation similar to |
| 141 | +events in Delphi. |
| 142 | + |
| 143 | +In both cases, the callback callables could be functions, instance or class methods, |
| 144 | +partials and lambda functions. The `inspect` module is used to define the signature for |
| 145 | +callbacks, and to validate that only compatible callables are assigned. |
21 | 146 |
|
22 | 147 | |donate|
|
23 | 148 |
|
|
0 commit comments