Wheel-reinvention with Python

[Peter Decker]

On 7/30/05, Torsten Bronger <bronger at physik.rwth-aachen.de> wrote:

> > Well, wxPython itself is largely the work of a single person, but
> > I doubt that many consider that a reason to avoid it.
> 
> But the developer and contributor base is much larger, so the
> project has reached the critical mass.

So until it reached that critical mass, you would have argued against
supporting it or using it? That seems to be what you're doing here.
Dabo is about a year and a half along; IMO, its progress in such a
short time frame is a very positive thing, not at all a negative.

> > As far as your comment about 'slowing down' the app, I've found
> > that Dabo and pure-wxPython apps run indistinguishably. Perhaps
> > there are some microseconds of extra processing, but I sure
> > haven't noticed it.  And I don't think that the comment about
> > installing another package is fair; *anything* outside of the
> > standard distribution requires that, and Dabo is no more difficult
> > than copying to site-packages.
> 
> I didn't want to say that Dabo is bad.  I just wanted to point out
> that its presence (and the presence of comparable projects) doesn't
> ease the IMO unfortunate situation with GUI toolkits for Python.

Perhaps, but I see it differently, since Dabo doesn't attempt to add a
new toolkit. I greatly preferred the look of wxPython over TkInter and
PyGtk, since I do a lot of cross-platform work. But while I liked the
results, I didn't like coding in wxPython. Dabo is giving me the best
of both worlds: a Pythonic language, and great-looking GUI apps. So I
feel that it is improving the situation with GUI toolkits for Python
in that it is allowing me to use the best toolkit without having to
write un-Pythonic code.

It would be great if the wxPython folks would adopt Dabo, and
eventually integrate it so that there is but a single, Pythonic way of
working with wxPython, but it seems that they have their hands full
just wrapping the C++ code of wxWidgets.
-- 

# p.d.