There are a couple of assert statements in the codebase which can make jw-pkg fail without any detail whatsoever if --backtrace is not specified, fix that.
FileContext's _open() and _close() are called everytime their wrapper is called, which tasks the caller with keeping track of whether they were already called or not. Be a little easier on the caller, keep track in an open count, and call _open() only once for multiple calls to open(), and close() likewise. The caller still needs to make sure the number of open() and close() calls matches.
- Add optional in_pipe and out_pipe parameters to __init__()
- Add a add_proc_filter() method
Add possibilites to attach input / output pipes to a FileContext instance. Data will be passed through the input pipe between ._get() and .get(), and through the output pipe between .put() and _put().
Add an async open() method which should allow to do what __init__() couldn't, because it's not async, and to match the already existing .close(). It's called by __aenter__() __aexit__() if the FileContext is instantiated as context manager, or at will when the user finds it a good idea.
All methods are async and call their protected counterpart, which is designed to be overridden. If possible, default implementations do something meaningful, if not, they just raise plain NotImplementedError.
Don't pass mode as a string to put(). Given the multitunde of possible string representations for numbers, some understood by int(string, 0) and some not, there's too much room for passing strings which are unparseable, or worse, prone to be parsed wrongly.
However, pass mode down to _put() as a string for convenience, because that's what most _put() implementations will need to use. If they don't, converting to int is easy from the one defined string format.
Add the parameter "atomic" to put() / _put(). If instructs the implementation to take extra precautions to make sure the operation either succeeds or fails entirely, i.e. doesn't leave a broken target file behind.
