Q:

is it necessary to call flush method of file handler in python

I saw a code where they were using file.flush(). so, i searched around and found This SO post. I kind of understood why there's a flush method. In the answer which was marked as answer the following was written 

Typically you don't need to bother with either method, but if you're in a scenario where paranoia about what actually ends up on disk is a good thing, you should make both calls as instructed.

So, i was wondering, when we open  a file using context manager and write some text, and then when the code exits from this context manager, there might be a chance that the text might not have been written to the file? if yes, why not python does this internally when file.close() is called?  is it being done already? 

A:

The file objects in the io module (the ones you get from open) and everywhere else you'd expect in the stdlib always flush when they close, or rely on platform APIs that are guaranteed to do so.
Even third-party libraries are required to "close and flush the stream" on their close methods if they want their objects to be file objects.1

The main reason to call flush is when you're not closing the file yet, but some other program might want to see the contents.

For example, a lot of people write code like this:
with open('dump.txt', 'w') as f:
    while True:
        buf = read_off_some_thingy()
        f.write(buf.decode())
        time.sleep(5)

… and then they wonder why when they cat dump.txt or open it in Notepad or whatever, it's empty, or missing the last 3 lines, or cuts off in the middle of a line. That's the problem flush solves:
with open('dump.txt', 'w') as f:
    while True:
        buf = read_off_some_thingy()
        f.write(buf.decode())
        f.flush()
        time.sleep(5)

Or, alternatively, they're running the same code, but the problem is that someone might pull the plug on the computer (or, more likely nowadays, kill your container), and then after restart they'll have a corrupt file that cuts off in mid-line and now the perl script that scans the output won't run and nobody wants to debug perl code. Different problem, same solution.

But if you know for a fact that the file is going to be closed by some point (say, because there's a with statement that ends before there), and you don't need the file to be done before that point, you don't need to call flush.

You didn't mention fsync, which is a whole other issue—and a whole lot more complicated than most people thing—so I won't get into it. But the question you linked already covers the basics.

1. There's always the chance that you're using some third-party library with a file-like object that duck-types close enough to a file object for your needs, but isn't one. And such a type might have a close that doesn't flush. But I honestly don't think I've ever seen an object that had a flush method, that didn't call it on close.

