Right now the naming and type convention for output functions' arguments is somewhat inconsistent. As identified in #523, there exist other common patterns and precedents for taking paths as well as file handles. Some functions also take only Path, and others take only TextIO.
It might be worth investigating if we can create a decorator to annotate functions to avoid these issues. This would allow the implementation itself to accept file as a file handle, and not have to worry about path processing. I'm personally a fan of numpy's simple definition as just file: file, str, or pathlib.Path for the public API, and have the decorator "convert" that into a file handle for the internal implementation (e.g. handling the context).
We should consider something similar if a function requires a directory or other kinds of templates if it makes sense.
Right now the naming and type convention for output functions' arguments is somewhat inconsistent. As identified in #523, there exist other common patterns and precedents for taking paths as well as file handles. Some functions also take only
Path, and others take onlyTextIO.It might be worth investigating if we can create a decorator to annotate functions to avoid these issues. This would allow the implementation itself to accept
fileas a file handle, and not have to worry about path processing. I'm personally a fan of numpy's simple definition as justfile: file, str, or pathlib.Pathfor the public API, and have the decorator "convert" that into a file handle for the internal implementation (e.g. handling the context).We should consider something similar if a function requires a directory or other kinds of templates if it makes sense.