This release is a pre-release and may not be stable for production use.
Overview
Core utilities and foundational code. It's relatively large but completely self-contained.
Notable packages
-
lang - The standard library of this standard library. Usually imported as a whole (
from omlish import lang), it contains an array of general purpose utilities used practically everywhere. It is kept relatively lightweight: its heaviest import is stdlib dataclasses and its transitives. Some of its contents include:- cached - The standard
cached_function/cached_propertytools, which are more capable thanfunctools.lru_cache. - imports - Import tools like
proxy_importfor late-loaded imports andproxy_initfor late-loaded module globals. - classes - Class tools and bases, such as
Abstract(which checks at subclass definition not instantiation),Sealed/PackageSealed, andFinal. - maybes - A simple, nestable formalization of the presence or absence of an object, as in many other languages.
- cached - The standard
-
bootstrap - A centralized, configurable, all-in-one collection of various process-initialization minutiae like resource limiting, profiling, remote debugging, log configuration, environment variables, et cetera. Usable as a context manager or via its cli.
-
collections - A handful of collection utilities and simple implementations, including:
- cache - A configurable LRU / LFU cache with options like ttl and max size / weight.
- hasheq - A dict taking an external
__hash__/__eq__implementation. - identity - Identity-keyed collections.
- sorted - Interfaces for value-sorted collections and key-sorted mappings, and a simple but - correct skiplist-backed implementation.
- persistent - Interfaces for persistent maps, and a simple but correct treap-backed implementation.
-
dataclasses - A fully-compatible reimplementation of stdlib dataclasses with numerous enhancements and additional features. The full stdlib test suite is run against it ensuring compatibility - they are dataclasses. Current enhancements include:
- Simple field coercion and validation.
- Any number of
@dc.initor@dc.validatemethods, not just a central__post_init__. - Optional generic type parameter substitution in generated
__init__methods, enabling accurate reflection. - An optional metaclass which removes the
need for re-decorating subclasses (with support for inheritance of dataclass parameters like
frozen), and some basic base classes. - (Nearly finished) support for ahead-of-time / build-time code generation, greatly reducing import times.
The stdlib-equivalent api is exported in such a way as to appear to be direct aliases for the stdlib api itself, simplifying tool support.
-
dispatch - A beefed-up version of functools.singledispatch, most notably supporting MRO-honoring method impl dispatch.
-
formats - Tools for various data formats, including:
-
http - HTTP code, including:
-
io - IO tools, including:
- compress - Abstraction over various compression schemes, with particular attention to incremental operation. For example it includes an incremental reformulation of stdlib's gzip.
- coro - Utilities for coroutine / sans-io style code.
- fdio - An implementation of classic selector-style IO dispatch, akin to the deprecated asyncore. While more modern asyncio style code is generally preferred, it nearly always involves background threads making it unsuitable for forking processes like process supervisors.
-
jmespath - A vendoring of jmespath community edition, modernized and adapted to this codebase.
-
manifests - A system for sharing lightweight metadata within / across codebases.
-
reflect - Reflection utilities, including primarily a formalization of stdlib type annotations for use at runtime, decoupled from stdlib impl detail. Keeping this working is notoriously difficult across python versions (one of the primary reasons for only supporting 3.13+).
-
sql - A collection of SQL utilities, including:
-
testing - Test - primarily pytest - helpers, including:
- 'harness' - An all-in-one fixture marrying it to the codebase's dependency injector.
- plugins/async - An in-house async-backend abstraction plugin, capable of handling all of asyncio / trio / trio-asyncio / any-future-event-loop-impl without having multiple fighting plugins (I know, I know).
- plugins - Various other plugins.
-
lite - The standard library of 'lite' code. This is the only package beneath
lang, and parts of it are re-exported by it for deduplication. On top of miscellaneous utilities it contains a handful of independent, self-contained, significantly simplified 'lite' equivalents of some major core packages:- lite/inject.py - The lite injector, which is more conservative with features and reflection than the core injector. The codebase's MiniGuice.
- lite/marshal.py - The lite marshalling system, which is a classic canned setup of simple type-specific 2-method classes and limited generic handling.
Lite code
A subset of this codebase is written in a 'lite' style (non-'lite' code is referred to as standard code). While standard code is written for python 3.13+, 'lite' code is written for 3.8+, and is written in a style conducive to amalgamation in which multiple python source files are stitched together into one single self-contained python script.
Code written in this style has notable differences from standard code, including (but not limited to):
- No name mangling is done in amalgamation, which means (among other things) that code must be written expecting to be
all dumped into the same giant namespace. Where a standard class might be
omlish.inject.keys.Key, a lite equivalent might beomlish.lite.inject.InjectorKey. - All internal imports
importeach individual item out of modules rather than importing the modules and referencing their contents. Where standard code wouldfrom .. import x; x.y, lite code wouldfrom ..x import y; y. As a result there are frequently 'api' non-instantiated namespace classes serving the purpose of modules - just handy bags of stuff with shortened names. - As lite code is tested in 3.8+ but core code requires 3.13+, packages containing lite code can't import anything
standard in their (and their ancestors')
__init__.py's. Furthermore,__init__.pyfiles are omitted outright in amalgamation, so they effectively must be empty in any package containing any lite code. As a result there are frequentlyall.pyfiles in mixed-lite packages which serve the purpose of__init__.pyfor standard usage - where importing standard packages from standard code would be done viafrom .. import lang, importing mixed-lite packages from standard code would be done viafrom ..configs import all as cfgs.
Dependencies
This library has no required dependencies of any kind, but there are numerous optional integrations - see
__about__.py for a full list, but some specific
examples are:
- anyio - While lite code must use only asyncio, non-trivial async standard code prefers to be written to anyio.
- pytest - What is used for all standard testing - as lite code has no dependencies of any kind its testing uses stdlib's unittest.
- asttokens / executing - For getting runtime source representations of function call arguments, an optional capability of check.
- wrapt - For (optionally-enabled) injector circular proxies.
- greenlet - For some gnarly stuff like the sync<->async bridge and the io trampoline.
- sqlalchemy - Parts of the codebase use SQLAlchemy for db stuff, but it is being migrated away from in favor of the internal api. It will however likely still remain as an optional dep for the api adapter.
Additionally, some catchall dep categories include:
- compression - Various preferred compression backends like lz4, python-snappy, zstandard, and brotli.
- formats - Various preferred data format backends like orjson/ujson, pyyaml, cbor2, and cloudpickle.
- sql drivers - Various preferred and tested sql drivers.
1 maintainer
Metadata
1 maintainer
Release files for omlish 0.0.0.dev387
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| omlish-0.0.0.dev387.tar.gz | 784.7 kB | Without provenance | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| omlish-0.0.0.dev387-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 1.9 MB
Release files / omlish-0.0.0.dev387.tar.gz
| Download URL | omlish-0.0.0.dev387.tar.gz |
|---|---|
| Size | 784.7 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
dd7b983fea9e7946760957081011e4371e3ee4f152db4daa1665d7c2e102cb27
|
|
BLAKE2b-256 checksum How to use checksums |
090ce7a7e94a595b28d37eae568e26e0b84aa1ff09123265c10eb52c7ee1dc9a
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/6.1.0 CPython/3.13.5
|
Release files / omlish-0.0.0.dev387-py3-none-any.whl
| Download URL | omlish-0.0.0.dev387-py3-none-any.whl |
|---|---|
| Size | 1.1 MB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
0af4ce089d7f438ecfb804e2bf79d29a09a39152a56208bec43520492bef0fcf
|
|
BLAKE2b-256 checksum How to use checksums |
55b899db302ef41125290ab23e18e1bbb2dac6d282daa3446ce7ff4983eabb02
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/6.1.0 CPython/3.13.5
|
Security for omlish 0.0.0.dev387
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.
No provenance found
None of the files in this release were uploaded with provenance metadata.
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.
