taskw package¶
Subpackages¶
- taskw.fields package
- Submodules
- taskw.fields.annotationarray module
- taskw.fields.array module
- taskw.fields.base module
- taskw.fields.choice module
- taskw.fields.commaseparateduuid module
- taskw.fields.date module
- taskw.fields.duration module
- taskw.fields.numeric module
- taskw.fields.string module
- taskw.fields.uuid module
- Module contents
Submodules¶
taskw.exceptions module¶
taskw.task module¶
-
class
taskw.task.Task(data, udas=None)[source]¶ Bases:
dict-
FIELDS= {'annotations': <AnnotationArrayField 'Annotations'>, 'depends': <CommaSeparatedUUIDField 'Depends Upon'>, 'description': <StringField 'Description'>, 'due': <DateField 'Due'>, 'end': <DateField 'Ended'>, 'entry': <DateField 'Entered'>, 'id': <NumericField 'ID'>, 'imask': <NumericField 'Imask'>, 'mask': <StringField 'Mask'>, 'modified': <DateField 'Modified'>, 'parent': <StringField 'Parent'>, 'priority': <ChoiceField 'Priority'>, 'project': <StringField 'Project'>, 'recur': <DurationField 'Recurrence'>, 'scheduled': <DateField 'Scheduled'>, 'start': <DateField 'Started'>, 'status': <ChoiceField 'Status'>, 'tags': <ArrayField 'Tags'>, 'until': <DateField 'Until'>, 'urgency': <NumericField 'Urgency'>, 'uuid': <UUIDField 'UUID'>, 'wait': <DateField 'Wait'>}¶
-
get_changes(serialized=False, keep=False)[source]¶ Get a journal of changes that have occurred
Parameters: - serialized – Return changes in the serialized format used by TaskWarrior.
- keep_changes – By default, the list of changes is reset after running
.get_changes; set this to True if you would like to keep the changes recorded following running this command.
Returns: A dictionary of 2-tuples of changes, where the key is the name of the field that has changed, and the value is a 2-tuple containing the original value and the final value respectively.
-
taskw.taskrc module¶
-
class
taskw.taskrc.TaskRc(path=None, overrides=None)[source]¶ Bases:
dictAccess the user’s taskRC using a dictionary-like interface.
There is a downside, though:
Unfortunately, collapsing our configuration into a dict has a jarring limitation – we can’t store both of the following simultaneously:
- color = on
- color.header = something
In this module, we err on the side of storing subkeys rather than the actual value in situations where both are necessary.
Please forgive me.
-
UDA_TYPE_MAP= {'date': <class 'taskw.fields.date.DateField'>, 'duration': <class 'taskw.fields.duration.DurationField'>, 'numeric': <class 'taskw.fields.numeric.NumericField'>, 'string': <class 'taskw.fields.string.StringField'>}¶
taskw.utils module¶
Various utilties
-
taskw.utils.clean_ctrl_chars(s)[source]¶ Clean string removing most (but not all) control characters
-
taskw.utils.convert_dict_to_override_args(config, prefix='')[source]¶ Converts a dictionary of override arguments into CLI arguments.
- Converts leaf nodes into dot paths of key names leading to the leaf node.
- Does not include paths to leaf nodes not being non-dictionary type.
See taskw.test.test_utils.TestUtils.test_convert_dict_to_override_args for details.
-
taskw.utils.decode_task(line)[source]¶ Parse a single record (task) from a task database file.
I don’t understand why they don’t just use JSON or YAML. But that’s okay.
>>> decode_task('[description:"Make a python API for taskwarrior"]') {'description': 'Make a python API for taskwarrior'}
-
taskw.utils.encode_task_experimental(task)[source]¶ Convert a dict-like task to its string representation Used for adding a task via task add
taskw.warrior module¶
Code to interact with taskwarrior
This module contains an abstract base class and two different implementations for interacting with taskwarrior: TaskWarriorDirect and TaskWarriorShellout.
If it is determined that there is a binary ‘task’ on the system and that it is of a sufficiently advanced version, then TaskWarriorShellout will be made the default TaskWarrior class. If not, then the default TaskWarrior class will fall back to the older TaskWarriorDirect implementation.
-
class
taskw.warrior.Command[source]¶ Bases:
objectEncapsulates available commands.
-
ALL= 'all'¶
-
COMPLETED= 'completed'¶
-
PENDING= 'pending'¶
-
-
class
taskw.warrior.DataFile[source]¶ Bases:
objectEncapsulates data file names.
-
COMPLETED= 'completed'¶
-
PENDING= 'pending'¶
-
-
class
taskw.warrior.Status[source]¶ Bases:
objectEncapsulates task status values.
-
COMPLETED= 'completed'¶
-
DELETED= 'deleted'¶
-
PENDING= 'pending'¶
-
WAITING= 'waiting'¶
-
-
taskw.warrior.TaskWarrior¶ alias of
taskw.warrior.TaskWarriorShellout
-
class
taskw.warrior.TaskWarriorBase(config_filename='~/.taskrc', config_overrides=None, marshal=False)[source]¶ Bases:
objectThe task warrior
Really though, a python object with methods allowing you to interact with a taskwarrior database.
-
classmethod
load_config(config_filename='~/.taskrc', overrides=None)[source]¶ Load ~/.taskrc into a python dict
>>> config = TaskWarrior.load_config() >>> config['data']['location'] '/home/threebean/.task' >>> config['_forcecolor'] 'yes'
-
load_tasks(command='all')[source]¶ Load all tasks.
Similar to TaskWarrior, a specific command may be specified:
all - a list of all issues pending - a list of all pending issues completed - a list of all completed issuesBy default, the ‘all’ command is run.
>>> w = TaskWarrior() >>> tasks = w.load_tasks() >>> tasks.keys() ['completed', 'pending'] >>> type(tasks['pending']) <type 'list'> >>> type(tasks['pending'][0]) <type 'dict'>
-
classmethod
-
taskw.warrior.TaskWarriorExperimental¶ alias of
taskw.warrior.TaskWarriorShellout
-
class
taskw.warrior.TaskWarriorShellout(config_filename='~/.taskrc', config_overrides=None, marshal=False)[source]¶ Bases:
taskw.warrior.TaskWarriorBaseInteracts with taskwarrior by invoking shell commands.
This is currently the supported version and should be considered stable.
See https://github.com/ralphbean/taskw/pull/15 for discussion and https://github.com/ralphbean/taskw/issues/30 for more.
-
DEFAULT_CONFIG_OVERRIDES= {'confirmation': 'no', 'dependency': {'confirmation': 'no'}, 'json': {'array': 'TRUE'}, 'verbose': 'nothing'}¶
-
filter_tasks(filter_dict)[source]¶ Return a filtered list of tasks from taskwarrior.
Filter dict should be a dictionary mapping filter constraints with their values. For example, to return only pending tasks, you could use:
{'status': 'pending'}
Or, to return tasks that have the word “Abjad” in their description that are also pending:
{ 'status': 'pending', 'description.contains': 'Abjad', }
Filters can be quite complex, and are documented on Taskwarrior’s website.
-
-
taskw.warrior.open(fname, mode)¶
Module contents¶
-
taskw.TaskWarrior¶ alias of
taskw.warrior.TaskWarriorShellout
-
class
taskw.TaskWarriorShellout(config_filename='~/.taskrc', config_overrides=None, marshal=False)[source]¶ Bases:
taskw.warrior.TaskWarriorBaseInteracts with taskwarrior by invoking shell commands.
This is currently the supported version and should be considered stable.
See https://github.com/ralphbean/taskw/pull/15 for discussion and https://github.com/ralphbean/taskw/issues/30 for more.
-
DEFAULT_CONFIG_OVERRIDES= {'confirmation': 'no', 'dependency': {'confirmation': 'no'}, 'json': {'array': 'TRUE'}, 'verbose': 'nothing'}¶
-
filter_tasks(filter_dict)[source]¶ Return a filtered list of tasks from taskwarrior.
Filter dict should be a dictionary mapping filter constraints with their values. For example, to return only pending tasks, you could use:
{'status': 'pending'}
Or, to return tasks that have the word “Abjad” in their description that are also pending:
{ 'status': 'pending', 'description.contains': 'Abjad', }
Filters can be quite complex, and are documented on Taskwarrior’s website.
-
-
taskw.TaskWarriorExperimental¶ alias of
taskw.warrior.TaskWarriorShellout