Doing Object Oriented (OO) implementation implies the system you are creating revolves around objects; in the case of Python applications, we use the word `instances'. OO applications call the instances that represent your problem's logical entities 'domain objects'. In a mail application, for instance, you might have Person and Message domain objects; in a sales application you could have Product and Sale.
Picking up from our last example, you could say NewsItem represented a class of domain objects, since its instances held data (or `state') that represented a logical container relevant to the task we had at hand, browsing news. This example was very simple, and there was no mechanism coded into the NewsItem class, but the concept is the same.
One very common problem when coding a new UI to manipulate the information in a domain object - at the fundamental level, in an instance - is the amount of code that needs to be done to alter the state of the instance. If you have a small form, with few controls in it, it's merely a bother; if you have a complex form, with many controls and lots of interaction, it can be a nightmare of accessors and message passing. Each widget must have the appropriate signals connected, and the handlers must either manipulate the instance directly, or call accessors repeatedly. Changing the UI involves more coding and complication.
So, in summary:
This is the task Proxies attempt to simplify.