On Mon, Feb 24, 2014 at 5:49 PM, Andrew Barnert <abarnert@yahoo.com> wrote:
But remember that there is an advantage to Gtk, Qt, etc. having their own language-agnostic idioms. They have a hard enough time documenting the whole thing as it is; if they had to write completely different documentation for C, C++, Vala, Python, .NET, etc., we just wouldn't get any documentation.
Point to note: When I'm trying to pin down an issue that relates to GTK on Windows, I'll sometimes switch between Pike and Python, since my installations of them embed different GTK versions. (I discovered a GTK bug that way.) Being able to translate my code from one language to another is extremely useful. And when I'm looking for docs and (especially) examples, it's really common to get them for some completely different language - it's easier to translate back from (say) Perl than to hunt down an example in the language I'm actually using. A more Pythonic wrapper around object creation would pretty much look like what I was saying, except that it would take specific coding work. Actually, probably all it'd take is a module that imports all the PyGTK classes and wraps them in Steven's chain() function. But the proposal I make here would put the power directly in the hands of the programmer, rather than requiring that the module support it. Why should method chaining be in the hands of the module author? ChrisA