This tutorial helped me, thanks! I couldn't grasp how Python just KNOWS that it should "open" and "close" the file, especially if it just KNOWS how to do these entry and exit functions for any other command that "with" is compatible with. I finally got it. In the file() example, file.open and file.close are versions of the generalized functions of "__enter__" and "__exit__," which are functions that exist in all sorts of python modules. "with" works by doing the "__enter__" and "__exit__" functions automatically. I feel like all the other tutorials I tried before this could start by saying that single sentence and everyone would say "Ohhhh".
probably it's incorrect that after with statement the object closes. Because when we use "with tensorflow.GradientTape() as tape:" we use tape even beyond the with statement.
I believe you should put the line where you open the file outside of the try statement. Otherwise, if the file doesn't exist, an error is raised, and in addition in finally you call the close on the file handler var which wasn't created. As a result, 2 errors raised.
Maybe you should close the video by saying: "Use the 'with open' syntax to optimize your file opening code realizing what's going on structurally within python"
What is it exactly that highlights syntax in your python console? I see this is explained in your other video clip: m.ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-cg_3E3Cb3MA.html Thank you for both! You’re a star!
2:58 The important reason for calling close() (or flush()) on an *output* file is so that you catch any I/O errors on the writes. Otherwise you could suffer loss of data without realizing it! Consider this littie script: f = open("/dev/full", "w") f.write("junk") That should raise “OSError: [Errno 28] No space left on device”, but because the script exits before the file is properly closed, you never see that. This version, on the other hand with open("/dev/full", "w") as f : f.write("junk") #end with does properly raise the error. As does f = open("/dev/full", "w") f.write("junk") f.close() but the with-statement version guarantees to flush the output even if some exception occurs before getting to the end.
Very interesting! I got a little confused on the last example though xD Is not the decorator already closing the file, making the f.close() inside managed_file function a little redundant?
I am now going to write context managed classes for connection objects. Love this! Note: one can write code to open a file, then read/write a file, but may or may not remember to close the file, and even if they do close the file, it's less likely to be done in a 'finally:' clause, so there is no guarantee it will be closed. The point is, try/finally wouldn't even get used for open/close (because people can write bad code, and it still seems to 'work'). This is why we have a context manager: to make python play nice with the OS. Also, I think the contextmanager decorator code communicates what it is better than the class code, even to someone who may not well understand decorators and generators.
2:27 That’s not a reason for using a with-statement. Remember that *all* Python objects keep track of their resources anyway, and free them when they disappear. And CPython is reference-counted, so this happens immediately the last reference to an object goes away.
3:33 Really the only situation where you could leak resources is when you are accessing some low-level API, for example via ctypes. In this case the calls you are making are equivalent to what you would do in a lower-level language like C, where you have to explicitly allocate and free all dynamic resources. The best thing to do in this situation is to create a Python wrapper for the lower-level C API, so the objects implemented by that API are represented by high-level Python objects that automatically manage their own resources just like any other Python object. In the wrapper you might use with-statements, try-finally blocks, and of course the __del__ method for making sure the lower-level resource-freeing calls are invoked before the Python object disappears.
Noob question -- can I use my own function in the statement and it operates normally? Like, def my_function( ): complex junk here with open('file') as fileObj: my_function( )
in this case, what purpose does opening the file serve? calling open('file') is effectively checking whether the file exists, yielding it and closing it without changing it. unless the "complex junk" manipulates said file, which opens another can of worms where the file is referenced before it is opened, let alone that my_function takes no parameters and thus *cannot* know what file you're referring to.
