cold shower request

wxPython Users
1

> data -> widget is easy with proper and liberal use of
> properties. With a bit of work, you can generate a set of
> automatic wrappers to handle the widget -> data transfer.
> Want to combine them all together? Well, hack a custom
> metaclass and you can use a Python class/subclass to handle
> the automatic wrapping, set up your event handlers, etc.

I'm sure it can be done with a bit of work. But it sort of
violates the "batteries included" attitude of which we are so
fond.

Batteries are only inlcuded if someone has taken the time to make them.
If no one has taken the time to make the batteries, then it is
impossible for them to be included. Don't get me wrong, being able to
use properly named methods without having to define callbacks sounds
like a great idea, as does the automatic binding of a value with a
control and vv, but I have a hard time asking for a feature if I am
unwilling to implement (or help implement) it myself. But hey, that's
just me. Feel free to demand anything you want of wxPython development,
I hope you get what you want.

> On the one hand, I agree. On the other hand, what about those cases
> where a user wants to add more than one event handler?

Don't know. I don't recall ever having to do that. The
objective (IMO) should be to make the 95% use-case as simple
and obvious as possible. I don't mind jumping through a hoop
the other 5% of the time, but don't make me jump through a hoop
all of the time for the benefit of the 5% case.

Here is an example that I have used myself in real code (see plugins/findbar.py
in the PyPE source distribution).

        box1.Bind(wx.EVT_TEXT, self.OnChar)
        box1.Bind(wx.EVT_TEXT_ENTER, self.OnEnter)
        box1.Bind(wx.EVT_KEY_DOWN, self.OnKeyDown)
        box1.Bind(wx.EVT_KEY_UP, self.OnKeyUp)
        box1.Bind(wx.EVT_KILL_FOCUS, self.OnKillFocus)

Some of those can probably be merged, but I prefer simple callbacks
whenever possible.

> They'll start asking "why can't I pass 10?" I think that it's
> easier and more consistant to support none than to support
> 1...? in a usable fashion.[1]

There's no reason to disallow explicit connection of handlers
to particular events, but why not make it easy to attach a
single handler to the most commonly used event? It seems to
work great for Tk.

And who decides what is the most commonly used event? For some controls,
the answer is obvious, but on other controls, the default event may not
be quite as clear-cut.

Me, I bypass those worries and write object factories to suit my task
whenever I need to create multiple objects of similar type. I like to
have them handle object creation, sizer addition, and event binding.
But hey, what goes in CPython core development (not all 5 line functions
should become a builtin), may not be applicable in the case of wxPython.

I would offer that if someone wants such default event bindings, that
one should sit down with the wxPython source and hack a patch together
to make such a thing happen, and remember to modify the documentation to
note the new argument, etc. Maybe it's not quite as easy as one would
expect.

- Josiah

···

Grant Edwards <grante@visi.com> wrote:

On 2005-11-07, Josiah Carlson <jcarlson@uci.edu> wrote:

2

> Don't get me wrong, being able to use properly named methods
> without having to define callbacks sounds like a great idea,

Not sure what you're referring to. I wasn't talking about
eliminating callbacks -- I was just pointing out that other GUI
packages have much simpler syntax/semantics for the mostly
common cases.

For example, onText() being called during a wx.EVT_TEXT on a wx.TextCtrl
(like apparently dabo does).

> as does the automatic binding of a value with a control and
> vv,

I don't know to what "automatic binding" refers either. The
feature I said was missing was binding a variable to a control
manually. I certainly wouldn't want it to be done
automatically, and can't even imagine how that would work.

control.Value = 5 -> control.SetValue(5)
c = control.Value -> c = control.GetValue()

This kind of thing is easily done with properties, and could easily be
optional (it seems as though dabo does this).

> Me, I bypass those worries and write object factories to suit
> my task whenever I need to create multiple objects of similar
> type.

And that's usually what I do. But when I have to wrap a button
100% of the time I use it, it seem to me that something is
missing. And when I pass the same argument value 100% of the
time when I instantiate a class, it seems that something is
wrong as well.

I'm sure the problem is that I'm not a "power user" of
wxPython, and that we who write fairly straight-forward
applications are being rightly ignored in the design of the
API.

It doesn't really surprise me that Python users haven't been consulted
in the interface; it's automatically generated based on the standard
wxWidgets definitions.

However, to deny that wxPython is low-level and unPythonic
compared to some other approaches is just sticking one's head
in the sand.

I'm not denying it. But I think that the reasons for why it isn't
completely and totally Pythonic (maybe like Dabo is looking to be, or is
wax more Pythonic?) is because manually wrapping every class is a pain
in the ass, and because attempting to be Pythonic in one way suggests
that not doing it in that way is unPythonic.

For example, imagine that an instance of wx.TextCtrl automatically bound
onText to a text event if it was defined during class instantiation.
Let us imagine that such a thing were Pythonic. Manually binding the
text event to a method on a different (containing) instance may be
considered unPythonic in the presence of the former mechanism, yet it is
not uncommon to see...

class ...(wx.Frame):
    def __init__(...):
        ...
        self.textbox = wx.TextCtrl(...)
        self.textbox.Bind(wx.EVT_TEXT, self.OnText)
        ...

or even the possibly offered...

        self.textbox = wx.TextCtrl(..., self.OnText, ...)

Do we pass event bindings, or do we rely on automatic bindings to
instance methods, or...? What about postponed event binding and
unbinding...

    control.onText = container.onText
    del control.onText

...

What I would offer is that in discussing what is or is not Pythonic,
that one should define what a "Pythonic" GUI toolkit is. After that
definition is created, discussed, etc., that it be offered to GvR (who
is the foremost expert on the definition of Pythonic).

Whether or not a PEP is created which says, "it would be really nice if
Python GUI toolkits adhered to the Pythonic GUI interface mechanism", in
a similar fashion to how WSGI and DBAPI define those interactions, is
another discussion.

- Josiah

···

Grant Edwards <grante@visi.com> wrote:

On 2005-11-07, Josiah Carlson <jcarlson@uci.edu> wrote: