[Python-ideas] `to_file()` method for strings

[Andrew Barnert]

On Mar 22, 2016, at 20:06, Nick Eubank <nickeubank at gmail.com> wrote:
> 
> As a social scientists trying to help other social scientists move from language like R, Stata, and Matlab into Python, one of the behaviors I've found unnecessarily difficult to explain is the "file.open()/file.close()" idiom (or, alternatively, context managers). In normal operating systems, and many high level languages, saving is a one-step operation. 
> 
>  I understand there are situations where an open file handle is useful, but it seems a simple `to_file` method on strings (essentially wrapping a context-manager) would be really nice, as it would save users from learning this idiom. 

Funny, I've seen people looking for a one-step file-load more often than file-save. But really, the two go together; any environment that provided one but not the other would seem strange to me.

The question is, if you stick the save as a string method s.to_file(path), where do you stick the load? Is it a string class method str.from_file(path)? That means you have to teach novices about class methods very early on... Alternatively, they could both be builtins, but adding two new builtins is a pretty heavy-duty change. Anything else seems like it would be too non-parallel to be discoverable by novices or remembered by occasional Python users.

I'd assume you'd also want this on bytes (and probably bytearray) for dealing with binary files.

Anyway, another huge advantage of this proposal is that it can handle atomic writes properly. After all, even novices can quickly learn this:

    with open(path, 'w') as f:
        f.write(s)

... but how many of them can even understand this:

    with tempfile.NamedTemporaryFile('w', dir=os.path.dirname(path), delete=False) as f:
        f.write(s)
        f.flush()
        os.replace(f.path, path)

(That's assuming I even got the latter right. I'm on my phone right now, so I can't check, but I wouldn't be surprised if there's a mistake there...)

One last thing: I think many of Cocoa, .NET, Qt, Java, etc. have a similar facility. And some of them come from languages that force everything to be a method rather than a function, which means they'd have good answers for the "where does from_file go?" question. Any serious proposal should probably survey those frameworks (along with the scientific systems--and probably how NumPy compared to the latter).

Actually, one _more_ last thing. Having this as a Path method makes sense; your problem is that novices don't discover pathlib, and experts don't use pathlib because it's not usable in most non-trivial cases (i.e., you can't use it even with stdlib modules like zipfile, much less third-party libs, without explicitly "casting" Path and str back and forth all over the place). Assuming that the long-term goal is to get everyone using pathlib, rather than just abandoning it as a stdlib fossil of a nice idea that didn't work out, copying its useful features like read_file and write_file out to builtins could be taken as working against that long-term goal. (Also compare Cocoa, which quasi-deprecated hundreds of methods, and then actually deprecated and removed some, to get everyone to switch to using NSURL for all paths.)