Tinyscript Internals¶
Proxy parser¶
This is a parser that collects calls to a common argparse.ArgumentParser
so that, inside the tiny script/tool, a few lines of code can be spared by not redefining the argparse.ArgumentParser
with its (long) parameters (e.g. the epilog).
Normal script :
...
if __name__ == '__main__':
parser = argparse.ArgumentParser(prog=..., epilog=..., ...)
parser.add_argument(...)
args = parser.parse_args()
...
With Tinyscript :
from tinyscript import *
...
if __name__ == '__main__':
parser.add_argument(...)
initialize() # also does many other things than just parsing !
...
Pre-defined help formatting¶
While sparing lines of code due to not redefining a complete argument parser, Tinyscript uses a pre-defined help formatting based on metadata, making very easy to build a well-formatted script/tool in only a few lines of code.
Here is an example of help output:
$ python tool.py -h
usage: tool [-h] [-v]
Tool v1.0
Author: John Doe (john.doe@example.com)
Reference: ...
Source: ...
Training: ...
This tool ...
optional arguments:
-h show usage message and exit
--help show this help message and exit
-v, --verbose verbose mode (default: False)
Usage examples:
python tool.py ...
Short/long help
The default behavior of help options is that "-h
" only gives usage information while "--help
" provides the full help message. This can be disabled using a parameter, see this section of the documentation.
Customizable initialization¶
This is achieved by passing arguments to initialize(...)
.
Various shaping and utility features are handled by this initialization and are explained in the related sections of this documentation.
Pre-configured colored logger¶
Tinyscript pre-configures a logger using the logging
and coloredlogs
modules, immediately accessible in the global scope when initialize
has been executed. If required, the logging format can be redefined.
Normal script :
import logging
logging.basicConfig(...)
logger = logging.getLogger(...)
...
With Tinyscript :
from tinyscript import * # from this point, a logger is already setup
...
LOG_FORMAT = "..." # new format can be defined
DATE_FORMAT = "..." # new format can be defined
...
if __name__ == '__main__':
...
initialize() # the logger is then reconfigured with the new formats
Advanced option clash resolution¶
When a developer writes a script/tool relying on Tyniscript, every argument or option defined will precede the default arguments, e.g. -h
or --help
. Tinyscript will then add these after the developer-defined ones, then using argparse
's conflict resolution first trying with full option strings (e.g. -v
and --verbose
), then with the long option string only (--verbose
). If a name collision occurs, some of the pre-defined arguments use prefixes or suffixes to resolve it so that they can still be parsed. The following lists give the mappings between pre-defined default option names and their resolved names if a collision occurs.
List of "extra" arguments and options:
Option strings | Description | If strings clash |
---|---|---|
--demo |
start a demo of a random example | --play-demo |
-h , --help |
show the help message | --show-help |
--step |
stepping mode | --step-mode |
--version |
show program's version number __version__ |
--show-version |
-v , --verbose |
verbose mode | --verbose-mode |
-w , --wizard |
start a wizard | --start-wizard |
List of "interaction" arguments and options:
Option strings | Description | If strings clash |
---|---|---|
--interact |
interaction mode | --interact-mode |
--host |
remote interacting host | --remote-host |
--port |
remote interacting host | --remote-port |
List of "timing" arguments and options:
Option strings | Description | If strings clash |
---|---|---|
--stats |
time statistics display (at end) | --time-stats |
--timings |
timing display mode | --timings-mode |
List of "report" arguments and options:
Option strings | Description | If strings clash |
---|---|---|
--output |
report output format | --report-output |
--title |
report title | --report-title |
--css |
report stylesheet file | --report-css |
--theme |
report stylesheet theme (overridden by --css ) |
--report-theme |
--filename |
report filename | --report-filename |
Pre-imports¶
Some common built-in or popular modules are preimported. Some others are enhanced to provide additional features. This can be inspected using the __imports__
dunder.
$ python
[...]
>>> from tinyscript import *
>>> pprint(__imports__)
{'bad': [],
'enhanced': ['code', 'codecs', 'hashlib', 'logging', 'virtualenv'],
'optional': ['bs4', 'fs', 'numpy', 'pandas', 'requests'],
'standard': ['argparse',
'ast',
'base64',
'binascii',
'codecs',
'collections',
'configparser',
'ctypes',
'fileinput',
'itertools',
'os',
'random',
're',
'shlex',
'shutil',
'signal',
'string',
'struct',
'subprocess',
'sys',
'time',
'types']}
In a script/tool, all these modules are preimported within the global namespace using the line from tinyscript import *
.
Modules can be loaded within a script/tool using the load(module, optional)
function. If setting optional
to False
(the default) and the module does not exist, the name will be appended to the __imports__['bad']
list.
Modules can also be reloaded using reload
(this of importlib
for Python 3, and the native one in Python 2 as it does not exist in importlib
for Python 2).
The modules in the __imports__['enhanced']
list are the native ones enhanced with additional features. These are enumerated in the enhancements section.
Virtual environment context¶
It is possible to manage a virtual environment from within the script using the virtualenv
module or the VirtualEnv
context manager. Each available function from the module can be accessed from a context manager instance.
...
with VirtualEnv("venv", "requirements.txt") as venv:
...
for package, version in venv.list_packages():
...
venv.install("my-package")
...