Warg 1.4.8

Description:

Warg 1.4.8

Warg

















Workflows















Devour everything :wolf:
Prey upon



Old-Norse: Varg
Only for use with Python 3.6+
This package is a selection of generalised small utility classes for many use-cases in any python project, a brief
description of each follow. No external dependencies, #pure-python. Warg is strictly only using standard library
functionality, hopefully forever..


A class for easing return of multiple values, implicit handling of args and kwargs and more. Neat access options to
the underlying __dict__ of the class instance, supporting almost any variation that comes to mind.


A class for executing any 'heavy' function asynchronously storing any results in a bounded queue. Note: communication
and organisation is costly, intended for heavy processing functions and general queuing.


A set of utility functions for parsing/sanitising python config files, and presenting attributes using common python
conventions and practices.


Some Mixin classes for iterating Mapping Types.


A single base class and metaclass, differentiating on whether subclasses singletons should be instated on own subclass
basis or on the supertype.


A wrapper class, shorthand "GDKC", for delayed construction of class instances, with a persistent set of proposed
kwargs that remain subject to change until final construction.


A "contract" decorator, "kw passing" is a concept that lets one make a contract with the caller that all kwargs with
be passed onwards to a receiver, this lets the caller inspect available kwargs of the the receiver function allowing
for autocompletion, typing and documentation fetching.


and more..


Disclaimer
I personally view the collection of tools as a general extensions of the python language for my workflow. I seek to
provide implementations and ideas that should remain valid and useful even through future versions of the python
language.
These tools are useful to me, I however suspect many of the assumptions and decisions that I made will be frowned upon
by more pythonic developers, hence why I would never propose any of these tools be provided in any other way than as
installable "extensions".
I seek to make the implementations quite easy to read and intuitive to experienced python developers, but I would
refrain usage of "warg" if collaborating with less experienced python developers that would not inspect the
implementation details of the package.
Lastly use "warg" with caution for long term projects, as some features might break as python naturally evolves in
future releases. Warg uses some advanced features of python and sometimes abuse notation/syntax, with some pretty hard
assumptions on parameter input and interaction.
With these rambling comments in mind please have fun with it


With great power comes great responsibility :wink: