<div dir="ltr">Thanks for the thoughts both!<div><br></div><div><span style="line-height:1.5">I'm not opposed to `a = str.read_file()` -- it does require knowing classes to grok it, but it's super readable and intuitive to look at (i.e. pythonic?). </span></div><div><span style="line-height:1.5"><br></span></div><div>Regarding bytes, I was thinking `to_file()` would include a handful of arguments to support unusual encodings or bytes, but leaving the default to utf-8 text. </div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Mar 22, 2016 at 8:52 PM Andrew Barnert <<a href="mailto:abarnert@yahoo.com">abarnert@yahoo.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>On Mar 22, 2016, at 20:29, Alexander Belopolsky <<a href="mailto:alexander.belopolsky@gmail.com" target="_blank">alexander.belopolsky@gmail.com</a>> wrote:</div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 22, 2016 at 11:06 PM, Nick Eubank <span dir="ltr"><<a href="mailto:nickeubank@gmail.com" target="_blank">nickeubank@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">it seems a simple `to_file` method on strings (essentially wrapping a context-manager) would be really nice</blockquote></div><br>-1</div><div class="gmail_extra"><br></div><div class="gmail_extra">It is a rare situation when you would want to write just a single string to a file.</div></div></div></blockquote><div><br></div></div><div dir="auto"><div>I do it all the time in other languages when dealing with smallish files. Python's very nice file-object concept, slant toward iterator-based processing, and amazingly consistent ecosystem means that the same issues don't apply, so I'd rarely do the same thing. But for users migrating to Python from another language, or using Python occasionally while primarily using another language, I can see it being a lot more attractive.</div><div><br></div><div>Also, you're neglecting the atomic-write issue. Coming up with a good API for an iterative atomic write is hard; for single-string write-all, it's just an extra flag on the function.</div></div><div dir="auto"><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"> In most cases you write several strings and or do other file operations between opening and closing a file stream.  The proposed to_file() method may become an attractive nuisance leading to highly inefficient code.  Remember: opening or closing a file is still in most setups a mechanical operation that involves moving macroscopic physical objects, not just electrons.    </div></div>
</div></blockquote><div><br></div></div><div dir="auto"><div>All the more reason to assemble the whole thing in memory and write it all at once, rather than streaming it out. Then you don't have to worry about how good the buffering is, what happens if there's a power failure (or just an exception, if you don't use with statements) halfway through, etc. It's definitely going to be as fast and as safe as possible if all of the details are done by the stdlib instead of user code. (I trust Python's buffering in 3.6, but not in 2.x or 3.1--and I've seen people even in modern 3.x try to "optimize" by opening files in raw mode and writing 7 bytes here and 18 bytes there, which is going to be much slower than concatenating onto a buffer and writing blocks at a time...)</div><br></div></blockquote></div>