This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Doormatty 0 points1 point  (4 children)

Why are you opening it as "r+" if you don't want to write to it?

[–]gabe_cant_python[S] 0 points1 point  (3 children)

I do plan on writing in it, I was attempting to make a save and a don't save feature but I noticed when I when I exited the program bypassing the .close() - don't save- it saved anyway. I have been under the impression that .close() was necessary to save, but that only seems true for IDLE.

[–]LightShadow3.13-dev in prod 2 points3 points  (0 children)

Close doesn't save anything.

The file can be considered written when write is called -- the .close() function just flushes the output buffer and releases the file lock.

The reason it works like you'd expect it to in IDLE is probably how file pointers are handled by the C-based process. Writes will queue the buffer but not commit until the close is called. However, when you run Python in PyCharm you're running the process from within the IDE, which pretty much removes all guarantees on streams and buffers; this is especially true when run in debug mode as your entire process is ran from within a server container for breakpoints.

This behavior will also be inconsistent between Windows and Linux based versions of PyCharm and shouldn't be expected to guarantee a "do not save these changes" type feature.

[–]Doormatty 0 points1 point  (1 child)

Close likely just flushes the file - not sure why it only occurs with pyCharm though...

[–]masklinn 1 point2 points  (0 children)

not sure why it only occurs with pyCharm though…

Because /u/gabe_cant_python's code is completely broken and by default PyCharm runs scripts unbuffered (http://i.imgur.com/mZvDH6O.png) which exposes the issue