First, start to put this in perspective.
You will be using GTK. This is a huge C library built in 1993 using the best traditions of 1970s coding style. It was built to help implement the GIMP, a Photoshop competitor wanna-be with user interface blunders of legend. A typical gui field might have forty or more parameters, mostly repetitive, having getters and setters. There will be pain.
The GTK itself manages a complete dynamic type system in C using GObject. This makes debugging a special joy that requires manually walking through arrays of pointers to methods full of generic argument lists with implicit inheritance. You will also be jumping through Pango libraries when you least expect it, e.g., using a Pango constant for where in a label the ellipsis go when the page is small. Expect more pain.
By now, you are probably vowing to wrap all your GTK interactions in a Model-View-Controller architecture specific to your application. This is good.
Using Glade, or gtkBuilder, or Stetic, will help coral the huge coupling problem of forty parameters to a function. Glade provides a basic GUI builder to drag and drop components together. The parameters and inherited parameters are somewhat separated out. The output of Glade is .glade XML file which you will then read in, attach your callbacks ("signal handlers") to identically named functions, and query or update the in-memory version of that XML to get widgets that you then use pyGTK to manipulate. Glade itself is a creaky and not well maintained.
Using pyGTK gives you annoyingly fine grained control in order to build your GUI. This will be verbose, copy-and-paste code. Each attribute will be a separate function call. The attribute setter does not return anything, so chaining the calls is out of the question. Usually, your IDE will give only minimal help on what functions mean and you will be constantly referring to DevHelp or some other tool.
One would almost expect GTK GUIs were meant to fail.