[Python-ideas] `to_file()` method for strings
Michael Selik
mike at selik.org
Mon Mar 28 21:04:21 EDT 2016
Brevity may be the soul of wit, but I am completely happy without a
convenience function to open and read/write, then close a file. In
production, the ``with`` statement seems concise enough. If I'm messing
around at the prompt we can already write ``text = open(filename).read()``.
We can also write ``open(filename, 'w').write(text)`` and not worry about
closing the file in the basic Python prompt.
On Mon, Mar 28, 2016 at 8:49 PM Chris Barker - NOAA Federal <
chris.barker at noaa.gov> wrote:
>
> Just to make sure I follow: Chris, you're proposing a modification to
> garbage collection to clean up `open()` if `open()` is used by not closed
> and not assigned to anything so that `open(file).write(stuff)` is safe?
>
>
> Well, I wouldn't call it a proposal, more a random inspiration that popped
> up when thinking about this thread.
>
> That sounds brilliant to me, and totally meets my goal of having a
> "one-step" method for writing to disk that doesn't require users to develop
> a two-step mental model. If it's feasible (I have nothing but the most
> basic understanding of how the garbage collector works), that would totally
> obviate my desire to have a `to_file()` method on strings.
>
>
> IIUC, in the current cPython implementation, you do indeed have that --
> I've used it for years, long before context managers existed, and still do
> for quickie scripts.
>
> CPython uses a reference counting scheme: each time an object is
> referenced, its count is increased, each lost reference, and it is
> decreased. When the count goes to zero, the object is deleted. So in:
>
> Data = open(file name).read()
>
> The file object is created, given a refount of one. Then the read() method
> is called, creating a string, then bound to the name Data. When the next
> line is reached, the recount of the file object is reduced to zero, and the
> object is deleted. And the internal file pointer is closed before deleting
> the object.
>
> The "trick" is that the Python language spec does not require this kind of
> garbage collection. So jython, or pypy, or ironPython may not clean up that
> file object right away, it could hang around in an open and unflushed state
> until the garbage collector gets around to cleaning it up.
>
> But for short scripts, it'll get cleaned up at the end of the script
> anyway.
>
> The thing is that while I, at least, think it's a fine practice for
> scripting, it's really not a good idea for larger system development.
>
> Thus the general advise to use "with".
>
> As for any proposal, it dawned on me that while we don't want Python to
> require any particular garbage collecting scheme, I wonder if it would be
> possible (or desirable) to specify that temporary objects used on one line
> of code, and never referenced any other way, get deleted right away.
>
> It's actually very common to create a lot of temporaries on a line of code
> -- when you chain operations or methods. So it might be a small performance
> tweak worth doing (or it may not :-) )
>
> -CHB
>
>
> _______________________________________________
> 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160329/72c91364/attachment.html>
More information about the Python-ideas
mailing list