Re: [Python-ideas] `to_file()` method for strings
On 23 March 2016 at 15:44, Nick Eubank <nickeubank@gmail.com> wrote:
True -- my feeling is that if we're ok with defaults in a pathlib method, why not put them in a string method?
pathlib is explicitly about filesytem management and manipulation, while strings don't inherently have anything to do with filesystems, and only a little bit to do with serialisation (via str.encode). Having some lower level convenience functions in io may make sense (specifically io.write_bytes(path, data) and io.write_text(path, data, encoding=None, errors=None), but the str builtin definitely isn't the right place for the capability. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Tue, 22 Mar 2016 at 23:46 Nick Coghlan <ncoghlan@gmail.com> wrote:
I agree this has nothing to do with `str` or `bytes` directly and should not be exposed on those types. And if you look at the issue that Victor linked to, getting a function that behaves consistently for atomic file operations across OSs is very tough. I think it would be best is follow the advice Victor gave in the issue he linked to and for someone to make a library with defaults they think are reasonable for atomic file operations, put it on PyPI, and get community feedback before trying to add it to the stdlib.
On Wed, Mar 23, 2016 at 1:45 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
In this vein, what about just adding io.read() and io.write() convenience functions that take the same arguments as io.open() (with an added 'data' parameter for write()) and do the obvious "open file, return file.read_or_write(), close file"? This doesn't answer the atomic write question, but that wasn't in the OP. The OP's 'string'.to_file('some_file') would just be io.write('string', 'some_file'), and str.from_file('some_file') would be io.read('some_file'). Granted, both functions are 3 lines of Python, but they might well be used enough to be worth adding. -- Zach
The OP's
Nick's observation about the mental model may be correct ( though I don't think so, frankly), but if it is, then this isn't any better than: open("some_path", 'w').write(string) " I need to open a file to write something to disk" isn't any harder to grok than "I need the io module to write something to disk". It would be nice to not need the 'w' flag, though, but probably way too dangerous to simply make an file object writable if the write method is called! Though I think the way this thread is going is correct - quick reading and writing to disk requires a serialization format - making the string is a heavier lift than writing it to disk for anything but very simple text. -CHB
On Mon, Mar 28, 2016 at 9:23 AM, Ethan Furman <ethan@stoneleaf.us> wrote:
I'm coming around to this actually -- not because it's easier to grok than: data = open('some_file').read() but because it could be an atomic operation, and close the file properly. and Is easier to grok than: with open('some_file') as infile: data = infile.read() and heck, it would even keep the door open to being made a built-in in the future. Maybe it's time to hear from the OP on this one -- after all, most of us in the discussion are already really familiar with the options! -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
On 28 March 2016 at 17:30, Chris Barker <chris.barker@noaa.gov> wrote:
and heck, it would even keep the door open to being made a built-in in the future.
What's the huge advantage of being a builtin? Sure, I can understand the benefit of wanting it in the stdlib over being a 3rd party dependency or a "simple recipe you can add to your own code"[1], but what is the huge deal about avoiding an import? If it's about interactive use, you have PYTHONSTARTUP, or the config options of your environment of choice (for example, IPython). For scripts, a one-line import is certainly not something to worry about. And for teaching, you can't get very far in Python without knowing about imports, so it's not like you're needing an advanced concept here. Paul
On 03/28/2016 10:35 AM, Paul Moore wrote:
On 28 March 2016 at 17:30, Chris Barker wrote:
Personally, I have no idea. The way some folks are talking about how hard typing in `import blah` is, you'd think they had to write a metaclass to get the job done. __prepare__-__new__-__init__-ly yrs -- ~Ethan~
Well, I'm not the OP here, but:
If it's about interactive use, you have PYTHONSTARTUP, or the config options of your environment of choice (for example, IPython).
Well, I find I want to cut and paste code to-from interactive environment enough, and use enough different systems, that I never customize my environment like that.
No a very big deal, no -- but neither is using with .... :-) So forget I said that, and let's consider putting it in the io module. -CHB
Paul
2016-03-28 17:20 GMT+02:00 Chris Barker - NOAA Federal <chris.barker@noaa.gov>:
(Sorry, I didn't follow the whole thread, and I'm not sure that it's best place for my answer.) A quick reminder: this pattern raises a ResourceWarning to remind you that the state of the file is unknown. Flush to disk? Maybe. Maybe not. It's a good practice to run Python with -Wd to see this DeprecationWarning and ResourceWarning. Use -Werror to ensure that you handle correctly *all* warnings ;-) Victor
On Tue, 22 Mar 2016 at 23:46 Nick Coghlan <ncoghlan@gmail.com> wrote:
I agree this has nothing to do with `str` or `bytes` directly and should not be exposed on those types. And if you look at the issue that Victor linked to, getting a function that behaves consistently for atomic file operations across OSs is very tough. I think it would be best is follow the advice Victor gave in the issue he linked to and for someone to make a library with defaults they think are reasonable for atomic file operations, put it on PyPI, and get community feedback before trying to add it to the stdlib.
On Wed, Mar 23, 2016 at 1:45 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
In this vein, what about just adding io.read() and io.write() convenience functions that take the same arguments as io.open() (with an added 'data' parameter for write()) and do the obvious "open file, return file.read_or_write(), close file"? This doesn't answer the atomic write question, but that wasn't in the OP. The OP's 'string'.to_file('some_file') would just be io.write('string', 'some_file'), and str.from_file('some_file') would be io.read('some_file'). Granted, both functions are 3 lines of Python, but they might well be used enough to be worth adding. -- Zach
The OP's
Nick's observation about the mental model may be correct ( though I don't think so, frankly), but if it is, then this isn't any better than: open("some_path", 'w').write(string) " I need to open a file to write something to disk" isn't any harder to grok than "I need the io module to write something to disk". It would be nice to not need the 'w' flag, though, but probably way too dangerous to simply make an file object writable if the write method is called! Though I think the way this thread is going is correct - quick reading and writing to disk requires a serialization format - making the string is a heavier lift than writing it to disk for anything but very simple text. -CHB
On Mon, Mar 28, 2016 at 9:23 AM, Ethan Furman <ethan@stoneleaf.us> wrote:
I'm coming around to this actually -- not because it's easier to grok than: data = open('some_file').read() but because it could be an atomic operation, and close the file properly. and Is easier to grok than: with open('some_file') as infile: data = infile.read() and heck, it would even keep the door open to being made a built-in in the future. Maybe it's time to hear from the OP on this one -- after all, most of us in the discussion are already really familiar with the options! -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
On 28 March 2016 at 17:30, Chris Barker <chris.barker@noaa.gov> wrote:
and heck, it would even keep the door open to being made a built-in in the future.
What's the huge advantage of being a builtin? Sure, I can understand the benefit of wanting it in the stdlib over being a 3rd party dependency or a "simple recipe you can add to your own code"[1], but what is the huge deal about avoiding an import? If it's about interactive use, you have PYTHONSTARTUP, or the config options of your environment of choice (for example, IPython). For scripts, a one-line import is certainly not something to worry about. And for teaching, you can't get very far in Python without knowing about imports, so it's not like you're needing an advanced concept here. Paul
On 03/28/2016 10:35 AM, Paul Moore wrote:
On 28 March 2016 at 17:30, Chris Barker wrote:
Personally, I have no idea. The way some folks are talking about how hard typing in `import blah` is, you'd think they had to write a metaclass to get the job done. __prepare__-__new__-__init__-ly yrs -- ~Ethan~
Well, I'm not the OP here, but:
If it's about interactive use, you have PYTHONSTARTUP, or the config options of your environment of choice (for example, IPython).
Well, I find I want to cut and paste code to-from interactive environment enough, and use enough different systems, that I never customize my environment like that.
No a very big deal, no -- but neither is using with .... :-) So forget I said that, and let's consider putting it in the io module. -CHB
Paul
2016-03-28 17:20 GMT+02:00 Chris Barker - NOAA Federal <chris.barker@noaa.gov>:
(Sorry, I didn't follow the whole thread, and I'm not sure that it's best place for my answer.) A quick reminder: this pattern raises a ResourceWarning to remind you that the state of the file is unknown. Flush to disk? Maybe. Maybe not. It's a good practice to run Python with -Wd to see this DeprecationWarning and ResourceWarning. Use -Werror to ensure that you handle correctly *all* warnings ;-) Victor
participants (8)
-
Brett Cannon -
Chris Barker -
Chris Barker - NOAA Federal
-
Ethan Furman -
Nick Coghlan -
Paul Moore -
Victor Stinner -
Zachary Ware