Functions with common and simple file operations have started to repeat in my code. Many like this one, but with subtle differences for example:def do_something_with_file(file_name, access_mode, data):    with open(file_name, access_mode) as f:        f.do_something(data)This is my solution so far:import picklefrom functools import partialdef _open_file(func, access_mode, file_name, *args, **kwargs):    with open(file_name, access_mode) as f:        return func(f, *args, **kwargs)open_file = partial(_open_file, lambda f: f, 'r')read_lines = partial(_open_file, lambda f: list(f), 'r')write_lines = partial(_open_file, lambda f, d: f.writelines(d), 'w')load_pickle = partial(_open_file, lambda f: pickle.load(f), 'rb')save_pickle = partial(_open_file, lambda f, d: pickle.dump(d, f), 'wb')Example usage:write_lines('file.txt', data)pickle = load_pickle('file.pickle')It seems readable enough for simple tasks and more complicated function definitions could also be passed to partial instead of simple anonymous functions like above.Does anyone see any drawbacks of using this or has suggestions on how it could be improved?
Python common file operations generalization
python;python 3.x;functional programming
If it works for you why not.The definitions could be further simplified too:read_lines = partial(_open_file, list, 'r')load_pickle = partial(_open_file, pickle.load, 'rb')And possibly also extract the first two repeated tokens:__open_file = partial(partial, _open_file)read_lines = __open_file(list, 'r')load_pickle = __open_file(pickle.load, 'rb')With a bit more metaprogramming that could be done in a loop too andthere are probably also ways to convert the other two lambdas usingsomething from the operator module or so.You see where I'm going with this?Pointfree style isn't exactly themost readable after all (actually the comparison with Pointfree styleisn't the best, but it illustrates the point about combining functionswith combinators for decreased readability quite well).If I saw this in production I'd probably say that you aren't gonna needit.  While interesting there's simply not that much added value insaving up the definitions IMO.Also, how with open(...) etc. behaves is quite obvious - with thesedefinitions not so much.The underscore on _open_file suggests a private function, which itmight not be, depending on your module layout.  It looks like a usefulenough combinator, so could also be exported for reuse.open_file on the other hand looks useless:  What do you want to use aclosed file object for?Biggest complaint:  There are no docstrings.  So, help(_open_file)basically gives me the function signature, whereas help(load_pickle)gives me the documentation for partial - which might be correct, butis also completely useless.  In the interest of better understandablecode I'd probably not recommend to use this approach unless you figureout a way to assign docstrings to those function-like objects (I couldfind one with a quick search, but that doesn't mean there isn't one).