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

Thomas Nyberg tomuxiong at gmail.com
Wed Mar 23 00:35:05 EDT 2016


Not to knock too much on R, but this kind of thing was one of the things 
I always really hated about that language. Separating the operations of 
converting a string and then writing/printing/sending/etc. that string 
is just so much more flexible. It reminds me of the many objects I 
worked with in R that had natural print methods, but did not have 
natural conversions to strings (at least nowhere near as easy as it 
should have been). There were so many times that having the operations 
as separate steps (e.g. having print just call call __str__() or 
whatever) is so much better.

I understand the argument that it feels more natural to certain people, 
but it really incentivizes bad design imo. Definitely a big -1 from me.

On 03/22/2016 08:06 PM, Nick Eubank 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.
>
> Apparently there's something like this in the Path library
> (https://docs.python.org/dev/library/pathlib.html#pathlib.Path.write_text)
> , but I suspect most people have no idea about that method (I've been
> doing python for years and this has always been a personal frustration,
> and I've asked several others for better options and no one had one to
> offer), and it seems like it would make much more sense as a string
> method. If someone has a string they want to save to disk, I can't
> imagine anyone looking in the Path library.
>
> I respect the desire to avoid bloat -- the context manager or open/close
> idiom has just felt unnecessarily complicated (dare I say unpythonic?)
> for a common task.
>
>
> Thanks!
>
> Nick
>
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>


More information about the Python-ideas mailing list