How come wxPython isn't in the standard library?

[BJörn Lindqvist]

See: http://www.wxpython.org/quotes.php. especially:

"wxPython is the best and most mature cross-platform GUI toolkit,
given a number of constraints. The only reason wxPython isn't the
standard Python GUI toolkit is that Tkinter was there first." - Guido
van Rossum

Guess, that answers my question, but isn't "Tkinter was there first" a
very bad answer? :) It is kinda ugly too, so I wonder why it can't be
replaced? Or maybe another GUI library could complement it. IMHO,
having a good GUI library in the stdlib would make distributing GUI
apps much easier. Windows users (and many Linux users) doesn't like
searching the net to find and download lots of dependancies.

--
mvh Björn

[Steve Menard]

BJörn Lindqvist wrote:

See: http://www.wxpython.org/quotes.php. especially:

"wxPython is the best and most mature cross-platform GUI toolkit,
given a number of constraints. The only reason wxPython isn't the
standard Python GUI toolkit is that Tkinter was there first." - Guido
van Rossum

Guess, that answers my question, but isn't "Tkinter was there first" a
very bad answer? :) It is kinda ugly too, so I wonder why it can't be
replaced? Or maybe another GUI library could complement it. IMHO,
having a good GUI library in the stdlib would make distributing GUI
apps much easier. Windows users (and many Linux users) doesn't like
searching the net to find and download lots of dependancies.

I haven't used WxPython for a little while, but not long ago (less than
a year) it was dreadfully easy to crash a program if even a little
mistake happened. Add to that that WxPython prigram will silently eat
any unexpected exceptions, and you get a very hard to debug situation.

For me, this would sisqualify wxPython as a standard Library component.
Steve

[Roger Binns]

BJörn Lindqvist wrote:

IMHO,
having a good GUI library in the stdlib would make distributing GUI
apps much easier.

Anything that is in stdlib is somewhat constrained to the same release
schedule as the core Python. For example it would have been bad to do
the wxPython 2.4 to 2.5 transition during the 2.3 Python series.

If your issue is distributing applications, there are other solutions.
For example, look at http://dotamatic.sf.net which is written in
Python using wxPython and has Windows, Linux and Mac binaries. An
end user never needs to know or care what the application is written
in or libraries used, and there are no other depenedencies.

A more extreme example is http://www.bitpim.org where we have even more
fun stuff like XML, SSL, SSH, USB and many other libraries. Again the
end users don't ever need to know or care.

Roger

[StvB]

I had that 'problem' a couple of times, but it was just a matter of writing
my code more cohesively and organizing my exception hierarchy so that
certain exception clauses cover a more narrow range of code, and catch a
more wide range of exceptions.

I haven't used WxPython for a little while, but not long ago (less than a
year) it was dreadfully easy to crash a program if even a little mistake
happened. Add to that that WxPython prigram will silently eat any
unexpected exceptions, and you get a very hard to debug situation.

For me, this would sisqualify wxPython as a standard Library component.
Steve

[Roger Binns]

Roger Binns wrote:

Anything that is in stdlib is somewhat constrained to the same release
schedule as the core Python. For example it would have been bad to do
the wxPython 2.4 to 2.5 transition during the 2.3 Python series.

The other thing I failed to mention is that the wxPython API isn't very
Pythonic. (This doesn't matter to people like me who are used to GUI
programming - the wxPython API is very much in the normal style for GUI
APIs.)

There is an expectation that modules in the standard library are good
examples of Pythonic APIs, programming, documentation, self tests etc.

Roger

[BJörn Lindqvist]

Thanks for the replies. There seems to be some good reasons that
wxPython isn't in the stdlib yet.

It's too big:

1) wxpython src tarball is about 18M,
python's is about 8M. Adding wx to the standard would more than
triple the size of the standard distro.
IMHO, this is a no issue. It doesn't matter that much if the source is
8 or 26 mb. In fact, 8 mb is extremely small download for a
programming language.

Incompatible release schedules:
Anything that is in stdlib is somewhat constrained to the same release
schedule as the core Python. For example it would have been bad to do
the wxPython 2.4 to 2.5 transition during the 2.3 Python series.
I don't understand this argument really and would be happy if someone
would explain further. Why can't those people who compile the stdlib
just take whatever the lastest version of wxPython is, and include
that?

wxPython is not mature enough:
The other thing I failed to mention is that the wxPython API isn't very
Pythonic. I haven't used WxPython for a little while, but not long ago (less than
a year) it was dreadfully easy to crash a program if even a little
mistake happened.

Ok. Those are big problems. So wxPython is not good enough to earn a
spot in the stdlib yet. However, getting your Python module into the
standard library must be like winning the Nobel Prize for Python
module programmers. Atleast, if *I* had a chance to get a module I've
written into the stdlib, I would definitely sync my release schedule
and make my module as pythonic as possible. :) Maybe in the future it
can be included?

--
mvh Björn

[Stefan Behnel]

BJörn Lindqvist schrieb:

1) wxpython src tarball is about 18M,
IMHO, this is a no issue. It doesn't matter that much if the source is
8 or 26 mb.

I highly object. Size /does/ matter in many cases. Imagine what would
happen if wxPython was integrated. People would say: Ok, tkinter is in,
wxPython is in, why not PyQT, PyGTK and toolkit XYZ ?? I don't see any
reason why wxPython should be better than any of the other toolkits. And
if I was to vote for or against a redundant module that would totally
bloat the standard distribution, I wouldn't think twice about it...

In fact, 8 mb is extremely small download for a
programming language.

8MB is actually quite large and I'm happy that many Linux-Distros
(especially Handheld distros like Familiar) split the stdlib into various
packets that can be installed independantly. I actually hope that Python
3000 will make this easier by reducing inter-module dependencies when
restructuring stdlib.

Stefan

[Greg Steffensen]

wxPython and Tkinter are more portable than PyQT and PyGTK. Moreover,
wxPython is not just another toolkit... its a set of bindings to a very
active toolkit that also has bindings for C++, Java, Javascript, Perl,
Ruby, Basic, Haskell, .NET and Eiffel, among others. wxWidgets is
already something of an open-source standard, independent of Python's
relationship. If wxPython were included in the standard library, it
would become easier for developers to port code from those languages to
Python. And because wxWidgets is such a large project, Python would be
able to benefit from its progress, providing regular language
improvements with little effort from the Python devs.

As for the size issue, the fact that including wxPython would triple
the size of the size of the standard disto says more about the current
state of the standard distro than it does about wxPython. If the
Python devs intend to keep the standard distribution at less than 10 mb
forever, then I think world-domination is impossible. The universal
availability of a modern, portable gui toolkit is a major feature that
languages can provide, and if Python decides to reject this, then it
will lose popularity to other languages that don't. Assuming that
language penetration is a major motivator for the devs, I think that
wxPython inclusion really is something that we need to start
considering.

[Greg Steffensen]

Errr... QT and GTK obviously have many language bindings too... I'm
saying that wxPython is superior because it has lots of bindings and is
portable.

[James Stroud]

On Sunday 07 November 2004 06:43 am, BJörn Lindqvist wrote:

IMHO, this is a no issue. It doesn't matter that much if the source is
8 or 26 mb. In fact, 8 mb is extremely small download for a
programming language.

What am I missing here? Lets look at it from an END USER's perspective. I come
from a situation where I was sys-admin to where I am the 0 privelige user. I
wanted to install a python module. So I called in the sys-admin. He tried to
add it with RPM. This rpm depended on that rpm and that rpm depended on a
chicken which depended on an egg which, expectedly, depended on a
chicken--you can guess where this is going.

So I decided I would make my own little universe in my user folder building
everything from scratch.

To get Tkinter to work, I had to install Tcl/Tk and python, and probably some
other stuff I already forgot about (blt or something?). That was easy-ish,
but painful from an END USER's perspective.

I then tried wxPython to take advantage or something or the other module that
I guess I won't be able to use because I had to install (to make sure every
library was compatible) a bunch of other libraries (zlib, jpeg, pango, etc.).
Pango needed gtk+ and didn't like the one my machine already had. (I work at
an INSTITUTION, not my home office with my customized linux box.) That would
make two gtk distributions on my machine, causing too many problems for my
short term attention span to figure out. So I did the only reasonable thing
an END USER might do in this situation--I said screw it on wxPython and
whatever module that was that I wanted to use.

Lets try to see things with naieve eyes: how do we think an END USER with few
administrative priveleges but operating system choices might respond to a
situation like this? Right! He'll use M$ windows--guaranteed.

Now I think we understand why graphics libraries might have a tough time
making it into a standard distro. Personally, as an end user who only wants
to use a program and not re-compile his kernel and such, I vote for tweaking
out tkinter and making Tcl/Tk/blt/etc. part of the standard distro with that
18 mb otherwise required for wxPython (as cool as wx might be). One
installer, wham-bam-program.

James
--
James Stroud, Ph.D.
UCLA-DOE Institute for Genomics and Proteomics
611 Charles E. Young Dr. S.
MBI 205, UCLA 951570
Los Angeles CA 90095-1570
http://www.jamesstroud.com/

[Roger Binns]

James Stroud wrote:
[Tale of RPM hell, Linux library version hell elided]

Lets try to see things with naieve eyes: how do we think an END USER
with few administrative priveleges but operating system choices might
respond to a situation like this? Right! He'll use M$
windows--guaranteed.
A lot of what you experienced is due to the design and implementation
of Windows. Microsoft puts a lot of effort into binary backwards
compatibility. It is why only one Python installer needs to be made
and can support every version of Windows since Win 95.

In the Linux world, very little effort is put into binary backwards
compatibility for libraries, because things can just be recompiled.
You were a victim of that.

But it isn't Python's place to try to fix that. Recognising it as
a problem, the number one feature of almost every new Linux distro
is rescuing users from packaging and versioning issues. I'll
leave it up to your judgement as to whether any succeeded.
Now I think we understand why graphics libraries might have a tough
time making it into a standard distro. Personally, as an end user who
only wants to use a program and not re-compile his kernel and such, I
vote for tweaking out tkinter and making Tcl/Tk/blt/etc. part of the
standard distro with that 18 mb otherwise required for wxPython (as
cool as wx might be). One installer, wham-bam-program.

The reason why tkinter/Tk doesn't have such library issues is because
it doesn't use many libraries under the hood. It draws the widgets
itself, has less interoperability with printing, drag and drop,
internationalization, online help, inter-process communication, clipboard,
themes, preferences etc. As such it is perfect for simpler apps
and a good reason for being in the standard lib.

But if you want to "tweak out" tkinter so it did all that stuff, you'd
be re-implementing all those libraries (a considerable amount of work)
or using them, bringing everything back to square one!

Roger

[Roger Binns]

BJörn Lindqvist wrote:

Anything that is in stdlib is somewhat constrained to the same
release schedule as the core Python. For example it would have been
bad to do the wxPython 2.4 to 2.5 transition during the 2.3 Python
series.
I don't understand this argument really and would be happy if someone
would explain further. Why can't those people who compile the stdlib
just take whatever the lastest version of wxPython is, and include
that?

wxPython has chances and enhancements in the API over time. For example
moving from wxPython 2.4 to 2.5 changed the preferred package naming
scheme, added several new methods for when you want to use point/size
objects, provided a new mechanism for binding to events, several other
enhancements, a whole bunch of deprecations etc.

It is actually quite rare for code using wxPython to support both
version 2.4 and 2.5.

Now if Python 2.3.1 shipped with wxPython 2.4 and Python 2.3.4 shipped
with wxPython 2.5, many people would get upset since their code would
brea/be deprecated in various ways. The right thing to do would be
for Python 2.3.x to stick with the same version of wxPython. However
we would come full circle since many projects now only work with wxPython
2.5 (the improvements were well worth it).

The other thing I failed to mention is that the wxPython API isn't
very Pythonic.

I haven't used WxPython for a little while, but not long ago (less
than a year) it was dreadfully easy to crash a program if even a
little mistake happened.

Ok. Those are big problems.

The latter point is extremely rare these days.
spot in the stdlib yet. However, getting your Python module into the
standard library must be like winning the Nobel Prize for Python
module programmers.
Not quite. It is an indication that your module is of value to many and
that you have a reasonably good implementation. You also need to
have your rate of change approximately the same as Python.
written into the stdlib, I would definitely sync my release schedule
and make my module as pythonic as possible. :) Maybe in the future it
can be included?

The API being Pythonic has been one of the big debates in the wxPython
community. wxPython is a wrapper around the C++ wxWidgets library. The
C++ API is "normal" for the library and is what is documented. wxPython
is a Python version of that API. Some people (like me :-) are happy with
that. It is a normal GUI API and I have no issue reading and using the
docs. Other people want something that is like all the other Python APIs
they are used to, and Python specific documentation. The latter is also a
*lot* more work, and although some people have attempted it, there doesn't
seem to be any that have followed through for a long period of time.

Roger

[Maciej Katafiasz]

On day Sun, 07 Nov 2004 12:07:50 -0800 looked the Lord upon his prophet,
and the prophet was numbered among those called Greg Steffensen. And thus
spake the prophet:

wxPython and Tkinter are more portable than PyQT and PyGTK. Moreover,
wxPython is not just another toolkit... its a set of bindings to a very
active toolkit that also has bindings for C++, Java, Javascript, Perl,
Ruby, Basic, Haskell, .NET and Eiffel, among others. wxWidgets is
already something of an open-source standard, independent of Python's
relationship. If wxPython were included in the standard library, it
would become easier for developers to port code from those languages to
Python. And because wxWidgets is such a large project, Python would be
able to benefit from its progress, providing regular language
improvements with little effort from the Python devs.
That's not really true. wxWidgets is (IMHO) clearly inferior to PyGTK. It
has not as nice API (reminds me of Win32 API, which is disastrous), isn't
in my experience really stable, uses outdated gtk+ 1.2 on my primary
platform, and even gtk+ 1.2 isn't fully used, instead we have some strange
things for any non-trivial (or rather, non-LCD) widget, like treeview or
fileselector. I feel no urge to have yet another "standard" GUI in python
I won't ever use.
As for the size issue, the fact that including wxPython would triple
the size of the size of the standard disto says more about the current
state of the standard distro than it does about wxPython. If the
Python devs intend to keep the standard distribution at less than 10 mb
forever, then I think world-domination is impossible.
That doesn't change the fact that tripling the size is not something you
do everyday. Especially not for (again, IMHO) rather useless component.
The universal availability of a modern, portable gui toolkit is a
major feature that languages can provide, and if Python decides to
reject this, then it will lose popularity to other languages that don't.
This is untrue. Entire notion of "portable toolkit" comes from wrong
assumption there exists anything near portability in GUI. There simply
isn't anything like portable UI, and conversely, creation of any
"portable" toolkit is doomed since day zero.
Assuming that language penetration is a major motivator for the devs, I
think that wxPython inclusion really is something that we need to start
considering.

GUI toolkit isn't something a language should provide. Things that make
sense to be in standard library have to be universally available and
useful. Regular expressions are universally useful, GUI toolkit which is
very platform-specific isn't. So it doesn't make sense to include it in
stdlib. Especially not-so-good toolkits shouldn't be there (and as I said,
I don't consider wxWidgets to be good toolkit)

--
"Tautologizm to coÅ› tautologicznego"
Mathrick <mn****@wp.pl>

[Roger Binns]

Maciej Katafiasz wrote:

PyGTK. It has not as nice API (reminds me of Win32 API, which is
disastrous),
The original wxWidgets API was somewhat reminiscent of Microsoft's
MFC. There isn't anything "disastrous" about it. You have a
class hierarchy, methods and properties. What exactly is the
issue you have?
isn't in my experience really stable,
Care to substantiate that? (I mean now, not several years ago).
uses outdated gtk+ 1.2 on my primary platform,
wxPython works with both GTK 1 and 2. Until wxPython 2.5, Robin
couldn't find a way to distribute GTK 2 based binaries that would
work on any machine. You could compile yourself against GTK2.
non-LCD) widget, like treeview or fileselector. I feel no urge to
have yet another "standard" GUI in python I won't ever use.
Wherever possible, wxWidgets uses the native widgets. I ran the wxPython
demo and looked at both widgets you mention and they appear identical
to ones in other Gnome programs (I run Gnome for my Linux desktop).
GUI toolkit isn't something a language should provide.
It is *extremely* rare for a language environment not to provide a
gui and associated tools. About the only other major one I can think of
that doesn't is Perl. (You could argue that GNU C/C++ on Unix doesn't
either, but that is due to GUI deficiency on Unix. On other platforms
such as Windows and Mac, C/C++ does come with gui tools and libraries).
there (and as I said, I don't consider wxWidgets to be good toolkit)

I don't think that statement can be supported. wxPython/widgets has been
getting better constantly. However I don't think that wxPython should
be in the standard library because it is improving and has more frequent
release cycles, and I would like to take advantage of that.

Roger

[Greg Steffensen]

Now is better than never (and no one's advocating "right now").

[andrea valle]

Just 2cents about the supposed wx supremacy.

I started a project of an interface to draw graphs (vertices+edges) and
I lost a lot of time with wx. I started with wx because many people
seem to be it's better (and I effectively appreciated a lot many of its
features).
Anycase, actually the wx ogl classes are in phase of development and to
draw on the screen is uselessly complicated with Paint. I solved
elegantly my problem with Tkinter's Canvas and with its very powerful
system of tags.
I'm waiting for a wxpython equivalent of Canvas.

Best

-a-

Andrea Valle
Laboratorio multimediale "G. Quazza"
Facoltà di Scienze della Formazione
Università degli Studi di Torino
an**********@unito.it

[Stefan Behnel]

James Stroud schrieb:

What am I missing here? Lets look at it from an END USER's perspective. I come
from a situation where I was sys-admin to where I am the 0 privelige user. I
wanted to install a python module. So I called in the sys-admin. He tried to
add it with RPM. This rpm depended on that rpm and that rpm depended on a
chicken which depended on an egg which, expectedly, depended on a
chicken--you can guess where this is going.

I guess your sys-admin just forgot to install apt-for-rpm first.

Stefan

[Stelios Xanthakis]

BJörn Lindqvist wrote:

There seems to be some good reasons that
wxPython isn't in the stdlib yet.

One more: Maybe the wxPython folks should add some documentation first.

I've worked with PyGTK, PyQT, wxPython and Tkinter for writting some
wrappers and I was *not* impressed with wxPython. The only strength
of it is that it looks good almost everywhere. That is of course
important --that's why HTML interfaces are so popular today--, but
wx is very big and not so cool to program. One can even accuse it
of bloat.

OTOH, it is a fact that the program with the most users wins and
the bet today is software that runs everywhere. Perl and python
were there first. Then java and c# appeared. IMO, these languages
are terrible for interpreted programs but they have good standard
GUI libraries. If python had a good toolkit maybe java and c# wouldn't
exist. So the issue of std toolkit shouldn't been taken lightly.

Unless somebody does something, I see us all using a web browser as an
interface to our programs and then inventing tookits over javascript
though...
Stelios
---------
These are the opinions of my boss and not my own.

[Christophe Cavalaria]

James Stroud wrote:

On Sunday 07 November 2004 06:43 am, BJörn Lindqvist wrote:

IMHO, this is a no issue. It doesn't matter that much if the source is
8 or 26 mb. In fact, 8 mb is extremely small download for a
programming language.

What am I missing here? Lets look at it from an END USER's perspective. I
come from a situation where I was sys-admin to where I am the 0 privelige
user. I wanted to install a python module. So I called in the sys-admin.
He tried to add it with RPM. This rpm depended on that rpm and that rpm
depended on a chicken which depended on an egg which, expectedly, depended
on a chicken--you can guess where this is going.

Bad sysadmin, change sysadmin. All you need to do then if you aren't using
some apt-like is to install all the offending rpms with a single command.
Yes, you can pass multiple rpm files to the rpm -i command.

[Jon Perez]

BJörn Lindqvist wrote:

See: http://www.wxpython.org/quotes.php. especially:

"wxPython is the best and most mature cross-platform GUI toolkit,
given a number of constraints. The only reason wxPython isn't the
standard Python GUI toolkit is that Tkinter was there first." - Guido
van Rossum
I think there's another reason not to standardize on
wxPython and it's that its API is not at all pythonic.
It reminds me too much of a C++ API.

Tkinter's is far easier to use and learn. (PyGtk would be
2nd while PyQt's API, in my experience is just as C++-like and
hard to understand as wxPython's)

Tkinter's two real cons are that:

a) it is [supposed to be] ugly (but see my replies below)
b) it is an additional layer and thus slow

For both a) and b), one big hope for improvement is that
Fredrik Lundh's Tkinter 3000 / Widget Construction Kit (WCK)
has been revived. You can now do your own Tkinter widgets
in Python. WCK's API has the traditional pythonic design
(lean, mean, easy to learn) typical of Fredrik Lundh's creations
(like ElementTree and ElementTidy).

WCK widgets might actually provide better performance
as you don't have the additional Tk layer to go through
(or less of it). I also saw some work to allow Tk widgets
to be written in native Win32 over at effbot.org!

The fact that you can now easily do your own Tkinter widgets
using WCK also means that we might soon see a lot of WCK
widgets which are prettier than the Tk ones. There are
already some samples over at effbot.org.
Guess, that answers my question, but isn't "Tkinter was there first" a
very bad answer? :) It is kinda ugly too, so I wonder why it can't be
replaced?

Tkinter is a lot less ugly today than it used to be because
Tk has adopted a more native look (i'm talking about windows
here, dunno about other platforms). You can actually turn
off that non-standard tear-off menu widget (which I believe
is responsible for as much as 80% of the Tkinter is ugliy
comments) easily too.

Without that tear-off menu disabled, I bet you won't be
able to tell that a modern Tkinter app from a native Win32
one.

[Jon Perez]

Jon Perez wrote:

Without that tear-off menu disabled, I bet you won't be
able to tell that a modern Tkinter app from a native Win32
one.

should have read...

With the tear-off menu function disabled, I bet you won't
be able to tell a modern Tkinter app from a native Win32
one in many cases.

[Jeff Shannon]

Jon Perez wrote:

I think there's another reason not to standardize on
wxPython and it's that its API is not at all pythonic.
It reminds me too much of a C++ API.

Indeed, one of wxPython's design criteria is that it remains fairly
close to the underlying C++ API -- it is explicitly a fairly thin
wrapper, not a complete retooling. (Though there are several retoolings
built on top of wxPython, notably PythonCard.)

I think that, despite the sometimes awkwardness for Python programmers,
this is a laudable goal. For one, it means that it's that much easier
to combine Python and C++ in a single wxPython/wxWidgets multilanguage
application. For another, considering that wxPython is essentially a
one-man project, it means that Robin can spend more time exposing
functionality and less time hiding syntax, so that overall wxPython ends
up being more powerful than it would otherwise. ;)

On the other hand, I *do* agree that the non-Pythonic API does make for
a barrier in including wxPython in the standard library. The initial
learning curve for wxPython is rather steeper than that for Tkinter
(though it isn't at all bad if one already has C++ GUI programming
experience). Especially when starting from zero, it's easier to figure
out how to get a simple GUI running under Tkinter. The downside of
Tkinter is that it is, in general, less flexible and less powerful than
wxPython -- simple stuff is easier in Tkinter, but complex stuff is
generally harder.

Personally, I much prefer using wxPython. (But then, I did play around
with C/C++ Windows programming long before I discovered Python.)
However, I can also see that the Tkinter toolkit is more appropriate for
standard-lib usage than wxPython is. And really, it's not like it's all
that difficult to install both Python and wxPython when distributing an
application...

Jeff Shannon
Technician/Programmer
Credit International

[Christophe Cavalaria]

Jon Perez wrote:

Guess, that answers my question, but isn't "Tkinter was there first" a
very bad answer? :) It is kinda ugly too, so I wonder why it can't be
replaced?

Tkinter is a lot less ugly today than it used to be because
Tk has adopted a more native look (i'm talking about windows
here, dunno about other platforms).

Motif on Unix ! Ugliest of all ( well, maybe there is worse )

[R.Marquez]

Jon Perez wrote:

With the tear-off menu function disabled, I bet you won't
be able to tell a modern Tkinter app from a native Win32
one in many cases.

Question: Will a tkInter app change appearance when the user changes
from XP to Classic Theme (or any other 3rd party theme) accordingly
as wxPython apps do?

Will it use the standard Windows File Open/Save dialogs?

Just wondering, not meaning to be antagonistic.

-Ruben

[Peter Hansen]

Jon Perez wrote:

I think there's another reason not to standardize on
wxPython and it's that its API is not at all pythonic.
It reminds me too much of a C++ API.

Tkinter's is far easier to use and learn. (PyGtk would be
2nd while PyQt's API, in my experience is just as C++-like and
hard to understand as wxPython's)
This appears to be a matter of opinion. I found Tkinter
very difficult to understand, and never did get to the point
where I could just write code with it, always spending my
time frustrated with things not doing what I thought they
were supposed to do and having a hard time finding examples
that matched my goals.

Strangely enough, given how often people complain about wxPython's
documentation, I didn't really find Tkinter much better.
Tkinter's two real cons are that:
a) it is [supposed to be] ugly (but see my replies below)
b) it is an additional layer and thus slow

I also concede both of those points.

In a nutshell, it's very clear from the past discussions in
this forum that *both* frameworks have a place, along with
(apparently, though I've not used it) PyQT and some of the
less mature efforts that are trying to build on top of one
or more of these.

This is an area where one solution will never please everybody,
so asking for wxPython to go into the standard library is
pointless. Tkinter is there already so leave it be, but use
whatever you find to be most effective.

-Peter

[Jon Perez]

Yes. It looks like for the most part it will use the
Win32 controls instead of drawing its own.

R.Marquez wrote:

Question: Will a tkInter app change appearance when the user changes
from XP to Classic Theme (or any other 3rd party theme) accordingly
as wxPython apps do?

Will it use the standard Windows File Open/Save dialogs?

Just wondering, not meaning to be antagonistic.

-Ruben