Wheel-reinvention with Python
kay.schluehr at gmx.net
Sun Jul 31 21:48:43 CEST 2005
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.
> 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
> 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 ;)
More information about the Python-list