Re. PythonCard - was Re: Event-driven GUIs ...

[Robin Dunn]

>
> What I imagine is this:
>
> A GUI library that is built for Python, that interacts well with the
> Python library and all the native type. This library would, for
> instance, expect to get a Python list whne is needed a list of items. It
> would be written in C++ (or maybe C). It would be platform independent.
> The strength in this approach is that the core library could just as
> easily be extended in either Python or C/C++. This way, the community
> could develop nice higher-level widgets and really expand the toolbox.
> It could be used from either C/C++ or Python. This way, one could
> develop a C/C++ app with an embedded python interpreter, and GUI code
> could be run from either language, the transition would be easy.
>
> Many of these features now exist in wxPython.

I'd say nearly all, but that's just my slightly biased opinion... <wink>

> That is why I am using it.
> However, wxPython is a thin wrapper around a C++ class library. This is
> a good thing because it allows common documentation and the wrappers can
> be produced with SWIG.

But arguably not a *Good Thing*.  Mainly it just reduces complexity enough
that one single ordinary human can develop, enahance, maintain, and find/fix
bugs in the package and still have time for a real job and a bit of a life.
SWIG doesn't generate the best code, but it means that there is around a
quarter of a million lines of code that I don't have to maintain and debug
by hand!

> It is a bad thing because you end up writing
> Python code that is not natural (pythonic), and a whole lot more verbose
> and complex than it needs to be.

Since I have a strong C++ background I look at the world with an intermixed
C++/Python view, so I often have a hard time seeing the "non-pythonic"
issues with wxPython but I know they are there.  I've addressed many of them
at the SWIG layer and there have been a few contributions for the
wxPython.lib package for some more pythonic things at the Python layer.
I'll accept all contributed code that makes things easier.

> It also suffers some from performance
> issues do to translating from Python lists to wxLists, generating
> wrappers around C++ objects, etc.

I've recently had some ideas and added items to my todo list that will
probably help out in this area, so I think this will become less of an issue
over time.  On the other hand, for a large majority of things wxPython is
used for it is fast enough already.


> I don't understand the details, but
> the issues are there. wxWindows and Python also share a lot of duplicate
> functionality: sockets, database access, process control, file system
> manipulations, etc. etc.

Much of which can be turned off when compiling wxWindows, but there probably
will always be some overlap with the current architecture.


--
Robin Dunn
Software Craftsman
robin at AllDunn.com       Java give you jitters?
http://wxPython.org      Relax with wxPython!