[Python-ideas] Method chaining notation

Andrew Barnert abarnert at yahoo.com
Sun Feb 23 21:58:13 CET 2014


On Feb 23, 2014, at 3:51, spir <denis.spir at gmail.com> wrote:

> The 2 methods above are not semantically equivalent. In the mutative case, you're talking about one single *thing* (the representation of one thing in the model, correctly "reified" in code). This thing may be multiply ref'ed, because it is a thing and as such has multiple *aspects* or *roles* (or competences?). In the functional case, you making up new objects at every step, thus if there were ref's they would be broken. We should only use such a style for non-things, meaning for plain data (information) *about* things.
> 
> (This style is not appropriate for GUI widgets, which conceptually are things, and pretty often ref'ed. Instead widgets should be created on one go.)

But put that together with your other reply:

> That's what I was about to argue. I don't understand why the python wrapper does not let you construct widgets in one go, with all their "equipment", since it's trivial and standard style in python (except, certainly, for adding sub-widgets to containers, as the sub-widgets exist and need to defnied by themselves).

The cleanest way to do this would then be to build the initializer(s) declaratively, then initialize the (mutable) object in one go, right?

As for why PyGtk doesn't work that way, there are two reasons.

First, it's deliberately intended to make Python Gtk code, C Gtk code, Vala Gtk code, etc. look as similar as possible. Gtk has a language-agnostic idiom that takes precedence over each language's idioms. This means you only have to write examples, detailed docs, etc. once, instead of once for every language with bindings.

Second, from a practical point of view, it allow PyGtk to be a very thin wrapper around Gtk.

And if you want to know why Gtk itself wasn't designed to be more Pythonic... Well, it wasn't designed for Python. It was originally designed for C, and then updated for C and Vala. So it has C/Vala-focused idioms. That's the same reason Qt and Wx have C++ idioms, Tk has Tcl idioms, WinForms has C#/VB idioms, Cocoa has ObjC idioms, etc. Unfortunately, none of the major GUI libraries was designed primarily with Python in mind, so we have to adapt.


More information about the Python-ideas mailing list