PyGUI as a standard GUI API for Python?

[Michael Palmer]

On Sep 3, 12:57 pm, "Diez B. Roggisch" <de... at nospam.web.de> wrote:
> Michael Palmer schrieb:
>
> > The other, PyGUI, has an even nicer API and more docs but has
> > relatively few widgets implemented at this time. It also strives for
> > compatibility with several toolkits (two at this time), which I think
> > is the right idea.
>
> I disagree with that. Meta-wrappers like this will always suffer from
> problems, as they have difficulties providing a consistent api. For
> example wx is said to be very windows-toolkit-centric in it's API. Yes I
> know that it works under Linux with GTK, but it does not come as natural .

wax actually does a nice job at wrapping wxPython with a cleaner API.

> > So far, development of PyGUI seems to be a one-man effort, and it may
> > be slowed down by the attempt to develop the API and the
> > implementations concurrently. Could it be useful to uncouple the two,
> > such that the API would be specified ahead of the implementation? This
> > might make it easier for people to contribute implementation code and
> > maybe port the API to additional toolkits. It seems that this approach
> > has been quite successful in case of the Python database API. That API
> > defines levels of compliance, which might be a way of accommodating
> > different GUI toolkits as well.
>
> > I may be underestimating the difficulties of my proposed approach - I
> > don't have much practical experience with GUI programming myself.
>
> I think you do. The reason for the various toolkits is not because of
> python - it's the proliferation of toolkits that exist out there.

Right. But that is similar to the situation with relational databases.
There are so many of them that it's impossible to include an adapter
to each of them in the stdlib. The next best thing is to provide a
high-level API that abstracts away the differences.

> As long as none of these is "the winner" (and it doesn't look is if that's
> to happen soon), I doubt that one API to rule them all will exist - they
> all have their different strengths and weaknesses, and a python-API
> should reflect these.

I rather think that a standard API would cover a reasonable subset -
it should NOT contain the idiosyncrasies of each individual toolkit.

The anygui project, which has been dormant for a while, is another
attempt at a high-level api. Apparently, it tried to implement
backends for a lot of toolkits - which again may have been to
ambitious an agenda. Maybe someone who was involved in that project
might provide some insight.