Q:

Is there any reason for using classes in Python if there is only one class in the program?

I've seen some people writing Python code by creating one class and then an object to call all the methods. Is there any advantage of using classes if we don't make use of inheritance, encapsulation etc? Such code seems to me less clean with all these 'self' arguments, which we could avoid. Is this practice an influence from other programming languages such as Java or is there any good reason why Python programs should be structured like this?
example code:
class App:

# all the methods go here

a = App()    

A:

One advantage, though not always applicable, is that it makes it easy to extend the program by subclassing the one class. For example I can subclass it and override the method that reads from, say, a csv file to reading an xml file and then instantiate the subclass or original class based on run-time information. From there, the logic of the program can proceed normally.
That of course raises the question of if reading the file is really the responsibility of the class or more properly belongs to a class that has subclasses for reading different types of data and presents a uniform interface to that data but that is, of course, another question.
Personally, I find that the cleanest way to do it is to put functions which make strong assumptions about their parameters on the appropriate class as methods and to put functions which make very weak assumptions about their arguments in the module as functions.

A:

I often do the same myself for the managers parts of an app which, in theory, could be reduced to simple, very sequential, functional programming.
The main advantage to it (for me) is that it encapsulates well your main loop or your run-once execution, and it allows to configure that run and persist data efficiently and cleanly across blocks, fundamentally re-configuring it as needed without having to change the code itself. Not to mention the ability to subclass an execution to a different and extended one.
It also tends to be a lot easier to expand the main that way, then it is when you have a solid block of 200 lines throwing around rather cryptically scoped stuff.
The self, after you write enough Python, kinda goes away as an impedement, and personally I like how it immediately offers a visual distinction between what I will obviously want to persist across scopes, and what is a disposable element that I DO want to run out of scope and get collected as soon as a particular step is done.
Last but not least, some people will object orient anything they get their hands on, or won't be able to read it. I'm one of them :)

A:

1. I know of one use for this. 
Though this can be achieved by other means. It ensures that both modules - module_B and module_C uses the same instance of App and do not instantiate separate objects.
In module_A.py
class App:
   ....

a = App()

In module_B.py
from module_A import a

In module_C.py
from module_A import a

Of course, you could create separate objects but that was is not the intention of above modules. 
What if you did the following in module_D.py
from module_A import App
a = App()

2. [Pedantic]
You could avoid using classes and decompose your solution using only modules and functions. But won't that look ugly in a large program. Wouldn't you want to use object oriented paradigm in your program. All languages provide certain way to take advantage of OO. We all like some thing or the other and some do turn us off. Explicit is better than implicit is usually the Python way. Though this is not good enough reason for it's inclusion.

