Defining VCL-like framework for Python

[Paul Boddie]

Alexander Staubo wrote:
> 
> I've just delved headfirst into what I'm trying to convince myself is a
> small project. In this article I will throw around some ideas; forgive
> the high rant-factor but it's kinda late.

As we can see from the time on your article. ;-)

[Detailed description of Delphi cut]

> Imho, Python needs a better windowing toolkit than is provided by
> Tcl/Tkinter today. That's just me. Furthermore, Python does not have (at
> least afaik) a component-based system for building applications. Python
> provides many facilities that the VCL defines -- such as persistence and
> RTTI-like mechanisms -- but afaik there is no well-defined protocol for
> creating cross-module components.

Could you clarify what you mean by "cross-module components"? As for the Tkinter
issue, surely there are now more than ever some real alternatives to Tkinter for
developing graphical user interfaces. I note that wxWindows is now at version 2
and gaining some momentum - wxPython is even promoted on the wxWindows home
page.

[Description of goals cut]

> One definite guideline here is not to rely on third-party windowing
> system support: in other words, the project will not use wxPython,
> Tkinter or any other library, although not precluding the ability to
> write controls that use such libraries internally.

Could you explain this decision a bit more? It would seem to me that taking
advantage of one of the more established toolkits would save a lot of extra work
and allow you to concentrate on the "higher level" aspects of such a project.

[...]

> As a proof-of-concept application for the new Python VCL I vote for a
> Python IDE with an integrated debugger. Talk about ambitious. But think
> about it: We need an IDE, and we need a windowing toolkit that doesn't
> suck, and it could be a good idea to combine the two.

Arguably, Tkinter doesn't even "suck". Yes, people do wonder about the Tcl
dependence from time to time, but this is only really a consideration where
installation issues (restrictions, managing versions of lots of different
packages) are more important than usual.

> Note that the project I have delineated here is not about "reproducing
> Delphi in Python". At least not yet. :) I want mainly to steal a few good
> ideas, improve others, and create something that makes Python more
> valuable to those "visual" programmers out there -- one of whom I don't
> necessarily count myself, although I sure miss a good windowing toolkit
> in Python; it deserves one.

It would indeed be good to create such a tool, but I do question the need to
write an entirely new toolkit to achieve this.

Paul