Python open () vs..close ()

Question

Regarding syntax in Python

Why do we use open("file") to open, but not "file".close() to close it?
Why is it not "file".open() or vice versa close("file") ?

Answer 1

This is because open() is a function, and .close() is an object method. "file".open() does not make sense, because you mean that the open() function is actually a class method or an instance of the string "file" . Not all lines are valid files or devices that should be opened, so the way the interpreter should handle "not a file-like device".open() will be ambiguous. We do not use "file".close() for the same reason.

close("file") will require a file name search and then another search to see if there are any files belonging to the current process attached to this file. This would be very inefficient and probably there would be hidden traps that would make it unreliable (for example, what if it is not a file, but a TTY device instead?). It is much simpler and easier to simply reference an open file or device and close the file through this link (also called a descriptor).

Many languages ​​use this approach:

 f = open("file") # open a file and return a file object or handle # stuff... close(f) # close the file, using the file handle or object as a reference 

This is similar to your close("file") constructor, but don't be fooled by it: it closes the file using a direct link to it, and not the file name stored in the string.

The Python developers decided to do the same, but they look different because instead they implemented it with an object-oriented approach. This is partly due to the fact that many file methods are available for Python file objects, read() , flush() , seek() , etc. If we used close(f) , we would either have to change all the other methods of the file object to functions, or allow it to be one random function that behaves differently from the rest for no good reason.

TL; DR
The open() and file.close() consistent with OOP principles and good file practice. open() is a factory-like function that creates objects that reference files or other devices. After creating an object, all other operations on this object are performed using the methods of the class or instance.

Answer 2

Only a little less new than you, but I will give this opportunity, basically opening and closing - these are quite different actions in a language such as python. When you open a file, what you really do is create an object that will work in your application representing the file, so you create it using a function that informs the OS that the file has been opened, and creates an object that can use python use to read and write to a file. When the time comes to close the file, what you basically need to do is your application to tell the OS that it is made with the file and get rid of the object that represents the memory file, and the easiest way to do this is by using the method on the object itself. Also note that the syntax of type "file".open requires the line type to include methods for opening files, which would be a very strange design and would require a large number of extensions for the line type for anything else that you wanted to implement with this syntax. close(file) will make a little more sense, but it will still be a clumsy way to release this object / let the OS know that the file is no longer open, and you will pass the file variable representing the object created when the file was opened, and not a line pointing to the path to the file.

Answer 3

Usually you should not explicitly use "file".close() , but use open(file) as the contextmanager, so the file descriptor also closes if an exception occurs. End of problem :-)

But to answer your question, I assume that the reason is that open supports a lot of options, and the returned class differs depending on these parameters (see also io ). Therefore, it would be much more difficult for the end user to remember which class he wants, and then use the "class".open with the correct class. Please note that you can also pass "an integer file descriptor of the file to be wrapped." to open , this means that in addition to the str.open() method, you will also get int.open() . That would be a very bad OO design, but also confusing. I would not like to guess what questions will be asked in StackOverflow about this ( "door".open() , (1).open() ) ...

However, I have to admit that there is a pathlib.Path.open function. But if you have a Way, this is no longer ambiguous.

As for the close() function: each instance will already have a close() method, and there are no differences between different classes, so why create an additional function? There are simply no benefits.

Answer 4

In addition to what has been said, I am quoting the change log in Python by removing the built-in file type. He (briefly) explains why the class constructor approach using the file type (available in Python 2) was removed in Python 3:

File type deleted. Use open (). Now there are several different types of threads that can open in the io module.

Basically, while file("filename") creates an instance of file , open("filename") can return instances of different stream classes depending on the mode.

https://docs.python.org/3.4/whatsnew/3.0.html#builtins