Wheel-reinvention with Python

[Cliff Wells]

On Sun, 2005-07-31 at 12:48 -0700, Kay Schluehr wrote:
> Cliff Wells wrote:
> 
> > > My objection with wrappers around wrappers around wrappers is that I
> > > have no hope ever watching the ground. If some error occurs, which
> > > layer has to be addressed? Which developing group is reponsible? My own
> > > or that of team A, team B, team C ... ? The baroque concept is
> > > repulsive to me and only acceptable in case of legacy code that gets
> > > wrapped around old one and is dedicated to substitute it continously.
> >
> > Of course, Tkinter is still a wrapper around a third party library (Tk)
> > borrowed from a different language (Tcl) and written again in a third
> > language (C), much the same as wxPython.
> 
> Yes, sorrowly. But the discussion was focussed around another layer
> above wxPython, Tkinter etc. to make those toolkits more pythonic. Ed
> promised to support many GUI toolkits as backend in future ( reviving
> the failed AnyGUI approach ). That's o.k. as long as tedious
> maintenance is a fun job for some people and they do it right. I don't
> say that Ed produces crap, but I'll be carefull and wait a couple of
> years before using such kind of stuff in production code.

Well, more users means more bug reports, more feedback, more helping
hands ultimately.  The wait-and-see approach, while safer, is anathema
to open source.  Try it on toy apps.  If it works, it works.  If it
doesn't submit bug reports and help out a bit.

> > Your concerns are valid in a theoretical sense, but in practice make
> > little difference.
> 
> It makes all difference in practice. A few levels of stacking does not
> hurt in theory because it is easy to abstract them away by perfect
> machinery.

Having used wxPython for many years (although, admittedly not yet Dabo
[but I will next time I'm doing a GUI app]), I can say that the
machinery, while rarely perfect (and what in software is?), is entirely
serviceable.  I've hit my share of bugs, reported them, worked around
them, etc.  I've never yet been completely stymied by any issue I've hit
with this toolkit.  Dabo, being pure Python, is probably even easier to
deal with since if I did hit an issue I could probably fix it myself.

I'd say my 6 or 7 years of wxPython experience trumps your theoretical
concerns ;)

I'm not as certain I like the "multiple backend" approach however
(supporting both wx and tk, for instance).  What seems to happen with
those sorts of things is you get the intersection of functionality of
the two underlying systems with the outstanding benefits of neither.
Not to mention it makes any progress take twice as long since any
existing functionality must be replicated for each system.  I'd much
prefer to see Ed focus on one or the other [wxPython of course, since
I'm selfish <wink>].

> > If you are using Tkinter and it exposes a bug in Tk,
> > then you report to the Tkinter maintainers and they will get it fixed.
> 
> As long as the chain of layers does not break and the conveyor-belt
> rolls efficiently it's like living in theory ;)

That can be said of any software in existence.  Nearly every bit of
software you use is layered many times over.

Cliff

-- 
cliff at develix.com
http://www.develix.com :: Web applications and hosting :: Linux, PostgreSQL and Python specialists ::