Tkinter: The good, the bad, and the ugly!

[Adam Skutt]

On Jan 18, 9:27 pm, Corey Richardson <kb1... at aim.com> wrote:
>
> Why would you add in only a part of wxPython, instead of all of it? Is
> the work to cut it down really an advantage over the size of the full
> toolkit? From what I just checked, the source tarball is 40MB. Can that
> much really be added to the Python stdlib? What other alternatives are
> there, besides wxPython, that are perhaps a bit smaller.
>
The source tarball from the wxPython.org website contains a full
version of wxWidgets in addition to the actual wxPython
functionality.  A python distribution would  certainly contain solely
the latter and require the end user to already have wxWidgets
installed in a suitable fashion.  The actual full wxPython binding is
~100 MiB uncompressed, ~15 MiB compressed BZIP2, but it also includes
a lot of stuff that could possibly be removed and/or reduced, like
full documentation, examples, etc.  It can be shrunk even further by
taking a dependency on swig and regenerating the bindings at compile
time (they're shipped prebuilt).  At which point, it's pretty damn
small.  Not as small as all of the Tk functionality, I think, but well
under 10MiB compressed.

The problem to me isn't the size (though some might find it
objectionable), but the system dependencies you have to take:
wxWidgets requires GTK+ on UNIX, which requires a whole mess of crap
in term, plus swig, plus whatever else I may or may not be missing.
I'm also not 100% certain as to whether it's as portable as Tk is
today.

At any rate, if the size is an issue, culling widgets is a lot of an
effort for not much of a gain, especially when you look at the bigger
picture of, "Every file I have to download to build python from
scratch"  Minimizing what's in the Python distribution does not change
the size of the dependency set one bit, and that dwarfs the python
code in any case.  That is what you want to avoid in my opinion.

Adam