[Python-ideas] Method chaining notation
Stephen J. Turnbull
stephen at xemacs.org
Mon Feb 24 00:31:22 CET 2014
spir writes:
> On 02/23/2014 06:06 AM, Andrew Barnert wrote:
> > All you're arguing here is that PyGtk is badly designed, or that
> > Gtk is not a good match for Python, so you have to write
> > wrappers. There's no reason the wrapper has to be fluent instead
> > of declarative.
> 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,
*Because* it's a *wrapper*, which leverages the gobject-introspection
FFI. (gobject-introspection is an export-oriented FFI, rather than an
import-oriented FFI like ctypes.)
> 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).
I don't think you need to except subwidgets. They could be defined
recursively by including calls to their constructors in the
"description" of the parent. It might be tricky to find a pleasant
way to express placement in containers with flexible placement
disciplines, but for single-child, column, row, and grid widgets I
don't see a problem at all.
Now, that would be nice for initialization, but the GTK+ v3 API is
very dynamic and insanely complicated. I think it would take a huge
amount of work to do this at all well, and I suspect that your program
would benefit only from beautification of initialization -- everything
else would still look the same. (Of course many programs don't need a
dynamic UI; I suppose that would be a benefit.)
In any case, I don't find a "chained" API for something like GTK any
more attractive than the repetition of object being mutated. They're
both quite ugly, an accurate reflection of the underlying library
which tried to be a better Xt, but ended up equally messy, compounded
by being a lot bigger (and more poorly documented).
More information about the Python-ideas
mailing list